> # Something which concerns me w.r.t. adding autocnfiguration (at this
> # stage) to NetBSD is what happens when drivers are loaded at different
> # major numbers (different card order, extra device, etc).  Some sort of
> # "devfs" is then required, unless certain drivers force themselves to
> # load at specific entries, right ?
> 
> Or you have the /etc/name_to_major and /etc/driver_classes which
> halp make up the mess that is Solaris dynamic kernel loading...

With a real dynamic devfs (as FreeBSD is darned close to having- Poul's been
passing out patches that seem to mostly work now), name_to_major is not
required. The driver_classes file is a hint so you can fill things out in a
dependency tree that aren't directly obvious from hardware properties.


> Not that I'd be against dynamic kernel loading, mind you, since then
> only the needed devices would be loaded at boot time (kind of like
> a working LKM on steroids), but the overhead that I've seen as-
> sociated with this scheme has proven to be pretty high, not

I sure would like to see you quote some *real* numbers here (memory load,
actual comparative speed of boot) on this for several systems that actually do
this (not just Solaris). We've talked about this via email before, and, uh, I
don't believe you're stating this fairly.

You have to have a kernel linker. In FreeBSD, kern_linker.o, subr_module.o and
subr_kobj.o adds about 10K of text/data in a 300K generic kernel. The actual
runtime linker in Solaris is about the same- maybe a bit beefier, but about
the same.

In terms of drivers as modules instead of statically linked- well, let's
see:
quarm.feral.com > size /usr/src/sys/compile/GENERIC/if_wx.o /modules/if_wx.ko 
   text    data     bss     dec     hex filename
  15421     144       8   15573    3cd5 /usr/src/sys/compile/GENERIC/if_wx.o
  21564     252      28   21844    5554 /modules/if_wx.ko

Okay- that's a bit bigger. Probably could be trimmed.

The speed at which modules are loaded depends on the mechanism you use. In
Solaris, it's darned slow. That's because most of it (early on) is done via
callbacks to the PROM driver.

But when you say "pretty high", I sure would like to know what you mean.


> to mention that if you put in a new driver somewhere and somehow
> rearrange the ordering of the major numbers, it can be a headache.
> I'd like to see the drivers declare their own major numbers, possibly
> maintaining a sparse numbering scheme.  It would match most closely
> what we have today, except that the driver would declare its number
> (and type) on load rather than having a big ?devsw[] compiled in.

Drivers should not declare a centrally contended resource unless there's a
central registry for such major numbers. Drivers *should* create minor nodes
are control that allocation (possibly with hints for name binding) since it is
only the driver that knows what the minor bits mean.

-matt