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