Discussion below. See SH SCI/SCIF drivers for replacement implementation.
>>>>> "Jesper" == Jesper Skov <email@example.com> writes:
Jesper> Presently the serial device driver exports a definition
Jesper> specifying the configuration header for that particular
Jesper> driver. This definition is used in the IO driver to
Jesper> include the device driver config. This means that the
Jesper> device driver doesn't have to do it - but it also means we
Jesper> cannot have multible device drivers on the same platform.
Jesper> Two observations which I think are always true:
Jesper> o The device driver knows its config header and can
Jesper> include it itself.
Jesper> o Only the device driver should be using the config
Jesper> options in the device driver config - IO driver and
Jesper> tests/application code cannot assume any particular
Jesper> options to exist or have specific semantic meaning [and
Jesper> if they want to know of device-specific options they know
Jesper> which config file to include anyway].
I believe those observations are correct - in general.
There may be exceptional cases. For example we may have on-chip
support for both ethernet and serial, and because of stupid decisions
by hardware designers a config option for serial might affect the
implementation of the ethernet driver. Such cases should not be an
issue because the packages are not completely independent courtesy of
hardware constraints: the ethernet driver knows the name of the serial
driver's config header (although it should check pkgconf/system.h to
make sure that the package is not loaded).
Where the packages are really independent this stuff should happen at
the CDL level, using requires and implements properties, common
packages, and the like.
Jesper> Which leaves the question: any reason to keep it as is? As
Jesper> far as I can tell, we can remove the
Jesper> CYGDAT_IO_SERIAL_DEVICE_HEADER definition altogether and
Jesper> make the device drivers include the config directly.
Certainly worth a try. There is a backwards compatibility issue, but
I can live with that if we improve package encapsulation.
Jesper> Just wanted to make sure there is no grand plan behind the
Jesper> current way of things [which I possibly implemented - in
Jesper> which case there would be nothing grand about it, just
It is possible that some of this stuff dates back to the pre-CDL days,
or to the early days of CDL when things like interfaces were not
available and the relevant dependencies could not be expressed.
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id>23314