On 2004-02-09 pcah8322@artax.karlin.mff.cuni.cz wrote:

>
> >
> > That's exactly how bus probing works in Linux.  Each driver registers an
> > tables IDs it's interested in for further probing with the bus driver.
> >
> > Of course this doesn't work if the driver is not loaded at all, so you
> > have a few choices:
> >
> > (a) always load all drivers by either compiling them statically into the
> >     kernel or loading all modular drivers
> >      + no userspace involvement
> >      - wastes lots of memory
>
> That's what we have in *BSD, and it works okay, but there is no
> modularisation, so memory is wasted.

(d) separate probe functions that are either compiled in, permanantly
loaded, or loaded when new hardware is dected and then unloaded

(e) require a trivial amount of user input when new hardware is added and
have the user specify what module is needed.  The documentation should
narrow down the potential drivers to a small number of possibilities for
new hardware, which the user can then try until the correct one is found.
Drivers can be aliased to a name, so you should only need to type, say,
"hwact ne_pcmcia" to load the module once you know what it is.

  IMO, the ideal of NetBSD kernel configuration should be custom static
kernels, perhaps with a few dynamic modules for infrequently used
hardware.  With this assumption, I think (e) makes the most sense.  I
think the primary emphasis of a modular system should be in compiling
static kernels more easily (and encouraging well defined interfaces).

  The kernel could be moved to a two-stage configuration, one for
compile-time options and one for configuration.  Each port would have a
small number (ideally one) of standard first stage configurations (those
who want DEBUG or such can compile a different configuration).  The result
of the first stage is a compilation of object files of all possible
hardware for that port for static linking and the compilation of all
possible dynamic modules for that port.  The second stage would only need
the linker (and possibly the assembler), which could be integrated into
the base system (so static kernel config can be done without the compiler
set) and would create the necessary data tables and link the kernel as
specified in the second stage config file.  Third party binary only
software could be provided in both module and object form in a
standardized way.


Matthew Orgass
darkstar@city-net.com