This is the mail archive of the
ecos-discuss@sourceware.cygnus.com
mailing list for the eCos project.
Re: eCos Device Driver reorganization
>>>>> "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
development.
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
code.
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.
Bart