[ECOS] eCos Device Driver reorganization

Bart Veer bartv@redhat.com
Wed Apr 5 04:01:00 GMT 2000

>>>>> "Jesper" == Jesper Skov <jskov@redhat.com> writes:

    Jesper> To followup on Hugo's mail with some specific details for the
    Jesper> watchdog/wallclock drivers:

    >> The situation currently is that we have
    >> -------------------------------------------------------------------
    >> devs/wallclock/current/include/common_stuff...
    >> devs/wallclock/current/src/PLATFORMY_STUFF
    >> # all one dir, BAD
    >> devs/watchdog/current/include/common_stuff...
    >> devs/watchdog/current/src/PLATFORMY_STUFF
    >> # all one dir, BAD
    >> -------------------------------------------------------------------
    >> Here's how we assign more meaning to the english names of the dirs:
    >> net: network, common stuff.  Not the drivers.
    >> io: io, common stuff, not the drivers.
    >> Including common PCI and serial stuff.
    >> devs: device drivers (in the crufty bit twiddling sense)

    Jesper> So we clearly need a reorg. I have a suggestion below, but
    Jesper> I'm a bit in two minds over where to put the common stuff
    Jesper> and emulated devices.

    Jesper> Problem being that neither wallclock or watchdog really do
    Jesper> any IO (so putting them in the io/ hierarchy seems wrong).
    Jesper> On the other hand, for consistency's sake, I think the
    Jesper> common parts and APIs belong in the io/ hierarchy and the
    Jesper> drivers (real and emulated) in the devs/ hierarchy.

    Jesper> So:
    Jesper> -------------------------------------------------------------------
    Jesper>     io/wallclock/current/...
    Jesper>     io/watchdog/current/...
    Jesper>                           # Public APIs, common code, and tests.

    Jesper>     devs/wallclock/emulated/src/wallclock.cxx
    Jesper>     devs/wallclock/ARCH/PLATFORM/current/src/PLATFORM_wallclock.cxx
    Jesper>     devs/watchdog/emulated/src/watchdig.cxx
    Jesper>     devs/watchdog/ARCH/PLATFORM/current/src/PLATFORM_watchdog.cxx
    Jesper>                            # all separate components, GOOD
    Jesper> -------------------------------------------------------------------

    Jesper> The conversion of these drivers should also happen within
    Jesper> a couple of weeks.

One issue here: I am not quite sure why you want to put the emulation
code into a separate package. A common device package can serve some
or all of the following purposes:

1) define the interface provided by the various implementations, i.e.
   export a header file. This means a hardware-specific device package
   need not export any header files (although it can still do so in
   order to provide additional information). Having a per-class header
   file like this should simplify application and test case

2) provide test cases which should be passed by all implementations.
   Again hardware-specific packages may add additional test cases.

3) provide support code, e.g. buffer management, tty support for
   serial lines, ... Some classes of device will not have any such

4) provide a default implementation, typically a software emulation.
   This only makes sense for some devices, not all. It is hard to
   provide a default implementation for an ethernet interface, but a
   wallclock or watchdog can be emulated.

I do not think putting the emulation code into a separate package
actually gains you anything. Even if the target board provides a
suitable device, application developers may still decide that the eCos
device driver should not use it: the application may have its own uses
for the device. The emulated version could still be useful in such
circumstances. Hence the target specification in ecos.db would still
want to load both the common package and the emulation, you might as
well stick them into the same package.


More information about the Ecos-discuss mailing list