On 05/12/2019 15:07, Joel Sherrill wrote:


On Thu, Dec 5, 2019 at 7:56 AM Sebastian Huber <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@embedded-brains.de>> wrote:

    Hello,

    the next thing I would like to work on is a specification of the
    application configuration (e.g. confdefs.h defines).

    The confdefs.h header file is quite big and difficult to review.
    What do
    you think about splitting this file into smaller parts, so that
    confdefs.h consists of something like this:

    #include <rtems/config/classictask.h>
    #include <rtems/config/classicsema.h>
    #include <rtems/config/bdbuf.h>
    #include <rtems/config/posixthread.h>
    ...

    ?


I think this MIGHT be a good idea. But I think you might want to
look at the top and bottom of the file first. What files will instantiate the
data structures? There is also some error checking at the bottom
which probably could be a sub-file.

Will there be logic to prevent including them from any other file?

My goal is to make the configuration more modular so that the component configuration can be tested individually. This means tests should be able to just include a subset of the configuration. This is of course not the intended use case for applications.


What about file system configuration?

Once you decompose that, will there actually be enough content to
justify a file per manager/capability? I understand this makes it easier
to track to a manager.

Where do user init task/threads go?

Just random thoughts? I can see "capability" or "area" oriented files
but going down to a manager feels too fine grain.

Yes, I guess it will be a mix of areas and managers. Some configuration options are quite entangled, e.g. the bdbuf configuration influences the Classic AP task maximum, device drivers in a table, initial extensions in a table, etc.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Reply via email to