RFC: Core constructors.

[Thomas Doerfler]

Chris,

Chris Johns schrieb:
> 
> The constructor calling order is controlled. This is not left to chance.
> This is different to C++ constructors. I was concerned about using the
> term constructor because of this. I am happy to remove constructor and
> use initializer or any other suggestion if it helps.

This sounds perfect.

> 
>>> 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 :-)
> 
> The nodes pointers are in the text section and the nodes are in the data
> section. The node are used to build the ordered list. This is the issue
> that needs more consideration. I wonder if I can iterate with just local
> stack data and no extra node data. This would allow the nodes to be
> placed in the const (text) section. It will take longer but then again
> performance is not the issue here.

Very bad idea: Do you really have to order the list? I guess it is only
used ONCE (to call the constructor functions). If we have, say 50
constructors in the system and you perform a repeated search algorithm
through that list ("who wants to be initialized next?"), the runtime
impact might be acceptable.

Alternatively, the stack or a piece of the workspace/heap might be
another solution.

I don't like the idea of using RAM for things that are not required
during runtime. There are some nice little Coldfire chips with built-in
RAM, and we alredy have lost two potential RTEMS designs due to the
current memory requirements, so I am a bit picky here :-)

>>
>> 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?
> 
> I think this approach is performing a part of that function, but it is
> not automatic rather it is being engineered.
> 
>> 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.
> 
> I am not I understand what you mean with "lead to nothing".

Sorry, no offence meant :-)

I meant that one goal, to pull in only those modules that are really
needed for a system/application will not be met, when let's say the BSP
references more modules than intended. We all know that a printf in a
BSP will pull in LOT of stuff, and possibly this is inadverted.

> If you mean constructors being used in code that is not engineered
> correctly, then yes there would be no gain. The tool could be abused
> with poorly designed code how-ever I see the real positives. It provides
> a way to sequence initialisation without needing the RTEMS code to be
> modified or changed. From a quality point of view not touching code is
> important. That said we still need to control the call point for a
> specific class of constructors.

Once again: I think your approach is a real benefit for RTEMS, I did not
want to critizise it in any way. I just let my thoughts drift on what
might help to get a better granularity.

> 
>> 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.
> 
> Interesting idea. My concern is C offers no language support and so
> doing this would be difficult.

Would it really? My idea is that some linker/objdump/lib tricks might
lead to the way:
1.) make the linker link together all objects of a module (e.g. the
semaphore manager)

2.) link this "module object" against all knowingly referenced external
modules, without pulling these objects in (there is a ld option to just
pull in the references)

3.) Any undefined references left over indicate an unexpected dependency.

I have no idea whether this would directly work, but I think this would
allow us to detect unwanted references after code modifications rather
early, especially (but not only) in the BSP area.

But once again: this is beyond the scope of your improvements.

wkr,
Thomas.

-- 
--------------------------------------------
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.