On 17/12/2019 15:13, Joel Sherrill wrote:
My approach would be to place all the define evaluations into a #ifdef
CONFIGURE_INIT guard, so that #include <rtems/confdefs.h> provides
nothing to the C compiler if CONFIGURE_INIT is not defined.
Originally, the intent was that user code could use CONFIGURE_MAXIMUM_xxx
if CONFIGURE_INIT was not defined. We likely don't do this much in the
tests but
you could have a header file which did all the CONFIGURE_xxx defines, then
include <rtems/confdefs.h>. Every application file could use the
CONFIGURE_xxx
macros if you did an "appconf.h" type header. Then a "appconf.c" could
define
CONFIGURE_INIT and include rtems/confdefs.h.
Ok, this is an interesting use case. I am not sure if it is a good
application design if the global limits are widely visible and used.
I guess exposing the header includes is not necessary for this use case.
For this the general pattern would be:
#ifndef XXX
#define XXX default
#endif
#ifdef CONFIGURE_INIT
#if XXX needs configured data structures
#include <xxx.h>
XXX xxx_config;
#endif
#endif
Do we have all the rtems_xxx which fetch configuration data documented?
Those
may largely cover the use case I described.
Yes, but you have to make a trade-off between compile-time and link-time
constants.
Now I generally recommend putting RTEMS configuration and an init task
to start RTEMS services in a dedicated file and invoking main() to start
the application. There are some of the rtems-examples which follow this
pattern.
Yes, this is in line with what I have seen in applications.
--
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
