This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: ARM EABI port / static constructor priority removal


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

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

--Chris

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]