RFC: Core constructors.

[Thomas Doerfler]

Chris,

Chris Johns schrieb:
> 
> In the cpukit/rtems/src/semcreate.c file a constructor reference is added:
> 
> RTEMS_CTOR_REF( classic, semaphore );
> 
> The references are at the leaf of the tree and pull in all above. Each 
> constructor node has its pointer placed in a special section and a modified 
> linker script pulls those pointers together. This is similar to the sysctl 
> system in the TCP stack.

I like that approach. I do not know the details of the implementation,
but I assume, that the order of the CTOR nodes is defined by the linker,
so there is no way to define, whether let's say the semaphore CTOR is
called before or after the msgqueue CTOR?

I don't see a problem here right now, but it may come, when this
mechanism is to be used for other areas of the RTEMS code.

> 
> The downsize of this approach is the addition of extra data to hold the 
> constructor and the reference. The constructor is currently 20 bytes and a 
> reference is 4 bytes. The constructor size could be reduced as I did not try 
> to make it as small as I could while playing. A constructor only adds to the 
> size when you use the resource. In the case of the RTEMS API there are 13 
> constructors and you would only get all if you used every API resource. In the
> case of a task and semaphore application the overhead is 48 bytes. The 
> smallest the constructor could be come is 12 bytes with usage restrictions.

As long as these tables/lists are ROMable, I don't see a big deal here.
The code to call the initialization function would take roughly the same
size, and the dummy no-* functions would add to this :-)

Another question: where do you actually create the CTOR node? Is it a
part of the "semcreate" sourcecode file?

This would mean, that if a module calls rtems_semaphore_release(), but
nobody creates a semaphore, then rtems_semaphore_release() might try to
work, but the whole semaphore manager is not yet initialized.

Or is it in a separate sourcecode file which is referenced by each
source file that implements the semaphore object?

> I think the next layer up, the Classic, POSIX and ITRON API could be handled 
> in a similar way. There could also be a BSP set of constructors. If this is 

This is beyond the current scope, but wouldn't it be nice to have a
toll/checker, that could detect the relationship between different
"blocks" of code?

The constructor mechanism is quite elegant and useful, but it would lead
to nothing, when (stupid example) the msgqueue code would call functions
in the semaphore manager, or (quite broadly used) a BSP calls printf.

If we would define packages (like network, IMFS, DOSFS, classic
semaphores, classic message queues...) and would automatically check
(based on a "relationship" file), that only wanted references to other
packages are present (like DOSFS is based on libblock, but not on the
BSP, and not on printf) then we might ensure, that the granularity of
RTEMS could be easily maintained in the future.

Hm. This is really a bit off topic. But maybe the direction would be
quite nice :-)

wkr,
Thomas.


> 
> Comments ?
> 
> Regards
> Chris
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users


-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.