This is the mail archive of the ecos-discuss@sourceware.cygnus.com 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]

Re: Auto initialisation of packages


Nick Garnett wrote:
> lunn@ma.tech.ascom.ch (Andrew Lunn) writes:
> > 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. 

No, this scheme should not be encouraged: as a result of the way this works,
support for the device drivers is forced into *every* eCos program by
default, even when device drivers are not used, unless the package is
explicitly disabled. The sooner we can drop this scheme, the better.

> 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 {
> public:
>     cyg_io_init_class(void) {
>         cyg_io_init();
>     }
> };
> 
> // 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.

Nope. That's not quite right. Said static object would not be included
unless it is directly referenced from an object that the user in turn
references from somewhere else in their program.

Think about how you would get a reference to the "C library object" if the
users program was just:

#include <cyg/infra/diag.h>
void main() { diag_printf("Hello world\n"); }

Answer: it's not referenced and we lose - main is never called.

The One True Way (TM) is to improve the configuration system so that when
packages are enabled, they can register initialization routines. These are
in turn put into a cyg_package_start() which would then be in an
autogenerated file.

Jifl

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