Subject: Re: Port independent cdevsw[]
To: Lennart Augustsson <>
From: Chris G. Demetriou <>
List: tech-kern
Date: 10/15/2000 12:36:10 (Lennart Augustsson) writes:
> I suggest that we switch over to having a mostly port independent [bc]devsw
> tables.  There is still a need to have port specific drivers so I suggest the
> following design:
>     Set aside a part of the major device numbers for port specific driver,
>     say 0-255.  The table for this will be port specific.
>     The rest of the major numbers are port independent and stored in a
>     central table.
> This design would allow us to slowly move over to MI drivers since the
> old tables will still work.  To keep backwards compatibility we can
> just keep duplicate entries in the port specific tables and the new one.

this is insufficient.

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.

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.

I think there's something to be said for having unique
numbers across all ports, or at least all ports of a given
$(MACHINE_ARCH).  makes sharing files, e.g. makedev, and file systems
(including device trees) easier.

Also, any solution which defines the actual devsw structure
anywhere but the drivers is broken.

And, finally, as I've expressed before, I'm of a mind to have the
tables defined neither statically nor at config time, but rather
dynamically at run time from linker-assembled tables defined by
drivers that need them.  there are a few reasons for this:

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

(3) in fact, it's not technically hard, nor confusing, nor
    unpredictable, despite FUD to the contrary.  And some mechanisms
    for doing it are easily accomodated by some features that have to
    be present in every modern linker.  And you need constructors
    for other desirable desirable kernel features anyway.

Then, you end up with a list of #defines in each port.  Not optimal,
but at least you know you've not assigned a major, because the kernel
won't compile.  And, it's amenable to being cleaned up into a single
global table, too.