[ECOS] Auto initialisation of packages

Nick Garnett nickg@cygnus.co.uk
Thu Oct 28 03:45:00 GMT 1999

lunn@ma.tech.ascom.ch (Andrew Lunn) writes:

> Hi folks
> Im working on a new package for eCos which will need to be
> initialised, in a similar way to the cyg_uitron_start() and
> cyg_iso_c_start(). The documentation says to add my own
> cyg_package_start() routine which calls the cyg_uitron_start(),
> cyg_iso_c_start() and then my own my_package_start(). 
> When there are only a few packages this is OK but as eCos expands and
> new packages are added this becomes unmanagable. eg when the TCP/IP
> port is complete i expect there will be a cyg_tcpip_start(). There may
> also be a cyg_filesystem_start() etc.
> How about using the same magic as for device drivers. Each device
> driver declares a structure which is put into a special segment. Its
> the linkers job to pull all these structures together and it
> effectivly makes an array. On startup the code walks the array in this
> segment and does what needs to be done with the drivers.
> Why not use the same method for package start functions? What way its
> all automagic. You could add a start-order field so that packages that
> build on other packages have a higher value and so are started later
> rather than earlier in the sequence.
>         Andrew

Actually the right way to do this is to add a C++ class with a static
constructor that calls your package init routine. These can already be
prioritized to start up in a given order. The device driver table scan
is actually done in cyg_io_init() which is invoked from just such a
constructor. Here's the code from io/common/current/src/ioinit.cxx
that does this:

// This is a dummy class just so we can execute the I/O package 
// initialization at it's proper priority

externC void cyg_io_init(void);

class cyg_io_init_class {
    cyg_io_init_class(void) { 

// And here's an instance of the class just to make the code run
static cyg_io_init_class _cyg_io_init CYGBLD_ATTRIB_INIT_PRI(CYG_INIT_IO);

The packages that don't do this at present (clib, uitron etc.) were
done before we had proper constructor priority, and should now be
converted. The only reason we have the driver table stuff is that we
need the drivers to be entirely in C.

Nick Garnett           mailto:nickg@cygnus.co.uk
Cygnus Solutions, UK   http://www.cygnus.co.uk

More information about the Ecos-discuss mailing list