Re: Need help in figuring out how a scheduler is assigned to a task

2020-06-09 Thread Sebastian Huber

On 09/06/2020 08:18, Gedare Bloom wrote:


Richi,

On Mon, Jun 8, 2020 at 8:52 AM Sebastian Huber
 wrote:

On 08/06/2020 16:33, Richi Dubey wrote:


Thanks for telling me about the uniprocessor rule for having a single
scheduler for all the tasks. It makes sense. However I still cannot
find the code which actually links our processor to that scheduler!
Talking on a high level, I cannot find a code anywhere that tells
kernel/processor to use Simple scheduler for all the tasks when we
write #define CONFIGURE_SCHEDULER_SIMPLE inside a testcase(I could not
find anything related in the scheduler.h configuration file too). I
hope my doubt makes sense.

Depending on the configuration options, the header file
 defines a couple of data structures. One is
the _Scheduler_Table:

https://git.rtems.org/rtems/tree/cpukit/include/rtems/confdefs/scheduler.h#n239

This is how the scheduler is defined for an application. You can look a
the preprocessed header file to see all the data structures.


You will need to learn some techniques for navigating a large code
base. I don't know if there is a good tutorial out there, but check
out information about:
* ctags
* cscope
They can integrate with editors on *nix and provide you with
identifier/name/text search in an indexed database built from a
filesystem directory tree. Or you can use them from the command line
also. This is the best way to find code definitions and to navigate
code quickly. You can push/pop searches on a stack also, so you can
easily follow a function's control flow down, and then backtrace up.

UNIX utilities:
* grep
* ack (an updated variant of grep)
* find


To get an overview of the control flow, you can also use 
-finstrument-functions combined with the Event Records:


https://docs.rtems.org/branches/master/user/tracing/eventrecording.html

With the data you can create a flame graph:

http://www.brendangregg.com/flamegraphs.html

It is not a five minute job to set this up.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Need help with configuring and using user defined scheduler

2020-06-09 Thread Richi Dubey
Dear Dr. Chen,

Hi, I saw your patch and it shows how to introduce a new test in the
testsuite. As others suggested, I might not make my test anytime soon.
But thank you for sharing this with me and I am going to bookmark this
for future reference when I develop a(another) test for strongapa.

Thanks,
Richi.

On Tue, Jun 9, 2020 at 12:07 AM Kuan-Hsun Chen  wrote:
>
> Hi Richi,
>
> If you just want to build the testsuites in sptest, you have to add an option 
> like "-enable-tests=yes" when you call ./configure.
>
> Please have a look at git/rtems/testsuites/configure.ac, you should see Line 
> 48 has this condition.
> (Just dig out my patch here: 
> https://lists.rtems.org/pipermail/devel/2016-December/016600.html, and I did 
> something similar as you)
>
> Best,
> Kuan-Hsun
>
>
> On Mon, Jun 8, 2020 at 4:55 PM Sebastian Huber 
>  wrote:
>>
>> Hello,
>>
>> I am not really motivated to explain the old build system. I hope we can
>> create the RTEMS 5 branch soon and merge in the new build system.
>>
>> For experiments you can just modify the existing scheduler
>> implementation. This avoids changing anything in the build system.
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH 2/5] libfreebsd: Added ofw_if.h

2020-06-09 Thread Niteesh G. S.
Hello Christian,

I fixed this.

Thanks,
Niteesh.

On Sat, Jun 6, 2020 at 5:20 PM Christian Mauderer  wrote:

> Some style comments:
>
> On 04/06/2020 19:43, G S Niteesh Babu wrote:
> > This file is the RTEMS implementation of ofw_if.h in FreeBSD. The
> > ofw_if.h in FreeBSD is an autogenerated header file that maps the
> > OF_function calls to their respective implementation. But in RTEMS
> > this file maps the OF_functions directly to their FDT implementation.
> > ---
> >  cpukit/libfreebsd/dev/ofw/ofw_if.h | 63 ++
> >  1 file changed, 63 insertions(+)
> >  create mode 100644 cpukit/libfreebsd/dev/ofw/ofw_if.h
> >
> > diff --git a/cpukit/libfreebsd/dev/ofw/ofw_if.h
> b/cpukit/libfreebsd/dev/ofw/ofw_if.h
> > new file mode 100644
> > index 00..7b9bcaa24a
> > --- /dev/null
> > +++ b/cpukit/libfreebsd/dev/ofw/ofw_if.h
> > @@ -0,0 +1,63 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause
> > +
> > + *
> > + * @file
> > + *
> > + * @ingroup LIBFREEBSDOFW
> > + *
> > + * @brief Declaration of OFW functions.
> > + */
> > +
> > +/*
> > + * Copyright (C) <2020> Niteesh Babu 
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in
> the
> > + *documentation and/or other materials provided with the
> distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
> TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
> IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
> OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#ifndef _LIBFREEBSD_OFW_IF_H
> > +#define _LIBFREEBSD_OFW_IF_H
> > +
> > +#include 
> > +#include "openfirm.h"
> > +
> > +typedef void*ofw_t;
> > +
> > +int OFW_INIT(ofw_t ofw_obj, void *cookie);
> > +phandle_t OFW_PEER(ofw_t ofw_obj, phandle_t node);
> > +phandle_t OFW_CHILD(ofw_t ofw_obj, phandle_t node);
> > +phandle_t OFW_PARENT(ofw_t ofw_obj, phandle_t node);
> > +phandle_t OFW_INSTANCE_TO_PACKAGE(ofw_t ofw_obj, ihandle_t instance);
> > +ssize_t OFW_GETPROPLEN(ofw_t ofw_obj, phandle_t package, const char
> *propname);
> > +ssize_t OFW_GETPROP(ofw_t ofw_obj, phandle_t package, const char
> *propname,
> > +void *buf, size_t buflen);
>
> If we use FreeBSD Kernel style (which I would suggest for code that has
> to do with FreeBSD) you should indent the second line one tab more. Means
>
> ssize_t OFW_GETPROP(ofw_t ofw_obj, ...,
> void *buf, size_t buflen);
>
> That is:
>
> ssize_t OFW_GETPROP(ofw_t ofw_obj, ...,
> <1*tab><4*space>void *buf, size_t buflen);
>
> Take a look at some FreeBSD headers for that. For example
> rtems-libbsd/freebsd/sys/sys/rwlock.h.
>
>
> > +int OFW_NEXTPROP(ofw_t ofw_obj, phandle_t package, const char *prev,
> char *buf,
> > +size_t size);
> > +int OFW_SETPROP(ofw_t ofw_obj, phandle_t package, const char *propname,
> > +const void *buf, size_t len);
> > +ssize_t OFW_CANON(ofw_t ofw_obj, const char *device, char *buf, size_t
> len);
> > +phandle_t OFW_FINDDEVICE(ofw_t ofw_obj, const char *device);
> > +ssize_t OFW_INSTANCE_TO_PATH(ofw_t ofw_obj, ihandle_t instance, char
> *buf,
> > +size_t len);
> > +ssize_t OFW_PACKAGE_TO_PATH(ofw_t ofw_obj, phandle_t package, char *buf,
> > +size_t len);
> > +
> > +#endif /* _LIBFREEBSD_OFW_IF_H */
> >
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel