Discussion below. See SH SCI/SCIF drivers for replacement implementation.


>>>>> "Jesper" == Jesper Skov <jskov.uk> 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
    Jesper> cluelessness(tm)]

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.

Bart