Todd Vierling <tv@wasabisystems.com> writes:
> 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
> nodes.
>
> 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.

I guess I don't get your point: doing the transformations is simple,
and can be done several ways.  A simple table is the easiest.

However, allowing multiple device #s to indicate the same device in
kernel, unless you're doing something else to ameliorate the device
aliasing issue, will cause you to lose.


> : (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.

eh, there can reasonably be several kinds of loadable drivers: ones
which know their number for system-provided devices, others that
either try a number known to them but not necessarily system-provided,
or just ask the system to assign one.

the former are the ones that we ship as part of the system.  the
middle type are those that people load, and don't want to worry about
device node numbering/creation.


> 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.

it's not clear to me why you'd even bother.  putting them into one
table just makes life easier, and if the entries in the tables are
just pointers to the devsw tables that live in the device object
files, the cost of even a fair number of extra entries isn't going to
be significant.

of course, in the fullness of time, you also need to do locking and
reference counting around access to the device switch, probably, so
it's not clear that it matters much one way or another.


cgd