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
