Subject: Re: Port independent cdevsw[]
To: Chris G. Demetriou <>
From: Todd Vierling <>
List: tech-kern
Date: 10/15/2000 21:00:23
On 15 Oct 2000, Chris G. Demetriou wrote:

: You need to transform the device numbers from the old values to the
: new values (if any).  Otherwise, you get into the situation where you
: may have incorrect device aliases.

One possibility here is to permit multiple device major numbers to point to
the same physical device.  The `historic' number, arch-specific, can point
to device X, but you'll also find it in the MI table at a fixed number.  
MAKEDEV would then need a minor update to generate only the MI numbered

Along with this, you could also have the `historic' pointers drop out with a
COMPAT_DEVSW or similar kernel option.  Not that it would reduce kernel size
much if at all (since there's still a need for MD drivers), but it can
easily test if someone forgot to use the new nodes.

: also, if you're going to renumber and transform device numbers, you
: should adjust maxpartitions so they're uniform and "at least 16"
: probably 32.


: (1) you need good mechanism to add majors at run-time for
:     loadable drivers.  The "lkm dummy" garbage is simply
:     not sufficient, as far as i'm concerned.  Given that,
:     you should be able to use it for 'normal' devices too.
: (2) you can actually use the same mechanism for loaded drivers as
:     normal ones, making conversion to loadable drivers slightly easier
:     -- there's a lot of other stuff to be done.

Note that for (1) and (2) to work together, there still needs to be a
separation of dynamically loaded numbers versus fixed-assignment numbers so
that the latter group can grow without clobbering the former.  The loadable
driver numbers may be the only numbers that a DEVFS type filesystem would
use, but there's multiple good arguments for a fixed set as well.

You could have two dynamic tables, chosen by the top bit of the major
number; if the top bit is set, it's a dynamically loaded device.

(Implementation note:  The places where checking the [bc]devsw table are not
performance critical.  If we indirect to two or three tables based on
historic vs. MI-fixed vs. dynamic, the impact should be negligible.)

-- Todd Vierling <>  *
-- Speed, stability, security, and support.  Wasabi NetBSD:  Run with it.