Automatic manager initialisation (was: Re: How to enable IP Forwarding in RTEMS)

[Chris Johns]

Joel Sherrill wrote:
> Chris Johns wrote:
>>
>>  [hint: a similar system could be followed and used for score
>>         manager initialisation :-)]
> 
> 
> nudge nudge.. wink wink... do you know of any simple examples?
> 
> You are right.  This could be a simple mechanism to get avoid
> having manager code in when it is not needed.
> 

The sysctl header contains the definitions used. It is far more complex
than the RTEMS managers need, but shows the use of special sections to 
contain pointers to structs. Sysctl is nice as it shows a tree structure 
can be created. The sysctrl decls, marcos etc can be found in here:

http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/cpukit/libnetworking/sys/sysctl.h

The key to initialisation is:

http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/cpukit/libnetworking/sys/linker_set.h

Here is an example is its usage:

http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/cpukit/libnetworking/kern/kern_mib.c

Looking at the kern os version variable from this file:

SYSCTL_STRING(_kern, KERN_OSRELEASE, osrelease, CTLFLAG_RD,
               osrelease, 0, "Operating system release");
     ||
     \/
#define SYSCTL_STRING(parent, nbr, name, access, arg, len, descr) \
	SYSCTL_OID(parent, nbr, name, CTLTYPE_STRING|(access), \
		arg, len, sysctl_handle_string, "A", descr)
     ||
     \/
#define SYSCTL_OID(parent, nbr, name, ....) \
	static struct sysctl_oid sysctl__##parent##_##name = { \
		&sysctl_##parent##_children, { 0 },  \
		nbr, kind, a1, a2, #name, handler, fmt, 0, descr }; \
	DATA_SET(sysctl_set, sysctl__##parent##_##name)

The SYSCTL_OID macro creates a static 'struct sysctl_oid' variable 
called 'sysctl___kern_osrelease' and it is placed into the 
'set_sysctl_set' section.

RTEMS initialisation occurs with a specific call to 
'sysctl_register_all' in rtems_glue.c. The standard way to initalise 
sysctrl would be to iterate over the 'set_sysinit_set' data section list 
of 'struct sysinit' pointers invoking each handler in the specified order.

This is basically what RTEMS needs. The ordering means a controlled 
initialisation and a tree means layering. For example the RTEMS API is 
placed under the score root node, and under the RTEMS API can be its 
managers. Even the networking stack could be added.

I suspect a little clean up in the RTEMS code may be needed so manager 
initialisation is linked to an object create function. For example 
task_create, while task_delete without a task_create does not and 
returns an error. This will create the smallest footprint yet require no 
special object files, or special user initialisation hacks.

> It might not work on all targets though.  It might be ELF
> specific.

You could be correct. Which targets are not ELF ?

-- 
  Chris Johns