Re: [ECOS] ARM EABI port / static constructor priority removal

[Jonathan Larmour <jifl@eCosCentric.com>]

Chris Zimman wrote:
>> Also ugly. You break the nice packing model. Say i have an out of tree
>> package, a device driver for the wall clock on my hardware. The
>> current code allows my code to have a static initializer with priority
>> that is after I2C is up and running and it is totally independent of
>> the in tree code.

And also needs to be run _after_ the kernel code, but potentially before
the libc code (which may reference the RTC), etc.etc. It's just not
feasible while retaining modularity which is far more valuable.

>> I don't need to modify the in tree code at all. The
>> linker sorts it all out. Your suggestion would force me to modify the
>> in tree list of constructors.
> 
> With what you're talking about here, you'd have to modify cyg_type.h anyway

Not really. In cyg_type.h CYG_INIT_APPLICATION is defined, and priorities
60000 up to 65534 are free for application use.

> if you want to add a new init priority unless you want to keep it private,
> which is kind of bogus.  With the current model anyhow, you *have* to be
> aware of the ordering in cyg_type.h and known what values are assigned to
> which constructors.  That's pretty ugly in and of itself.

Arguably not with a reserved range for application use.

> There's also no inherent reason you would have to modify in tree code to
> accomplish what you're suggesting.  Sections can be created for just that
> purpose.  Even enforcing startup ordering rules is pretty straight forward
> that way.

It's potentially feasible to create a section (not .ctors, something
eCos-specific) that contains a list of tuples - a priority number and a
function pointer. But then a) the list needs to be sorted at runtime which
is very bad; and b) it seems very much that we're just swapping one
extension for another.

Although reworking our abstraction to _permit_ this mode of operation
(without requiring it for GCC users) might make eCos more portable to other
compilers by making this sort of thing possible.

>> The same could be said for application code. My application wants a
>> static constructor called after the OS is up an running, but before
>> main() is called. Should i modify the OS to list my application
>> constructors?
> 
> It's not about the use of static constructors in general, it's about relying
> on non-portable behavior with respect to using them (construction ordering).

It's not the best solution, but it may be the least worst.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
 **  Visit us at ESC Silicon Valley <http://www.embedded.com/esc/sv>  **
 **  April 15-17 2008, Booth 3012, San Jose McEnery Convention Center **
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss