Subject: Re: Port independent cdevsw
To: Chris G. Demetriou <email@example.com>
From: Todd Vierling <firstname.lastname@example.org>
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 <email@example.com> * http://www.wasabisystems.com/
-- Speed, stability, security, and support. Wasabi NetBSD: Run with it.