what is so wrong with major numbers? it is such a simple system. what driver,
what instance. major number, minor number. why is this such a bad scheme? 
as for removable devices that change, these can come in two flavors, i
think. the kind for which the variety of types is small and simple, as in
disks, where removable media are not a problem, and the kind which are
more greatly variegiated and complex, such as pcmcia devices, for which
there is no ssensible way to compile in a priori support for all devices
possible. In the former case, this shoudl be built in and thats that, the
way removable media support for scsi devices is done now and has been for
a long time. In the second case, the interface shoudl be handled by a
single driver and the individual support should be in userland
This is a case of having to make complications in th ekernel to accomodate
stupidly designed hardware and interfaces which were not well thought
out. it should be compartmentalized into a userland interface, to keep the
kernel from getting cluttered and klunky from having to deal with crap like
that. 

isildur

On Tue, 20 Feb 2001, Matthew Orgass wrote:
<snip> 
>   It is a bigger change, but you do not need to do the major number
> removal now.  You would still have a driver flag day, but it would save
> adding yet another properties mechanism.
> 
> > Getting rid of major/minor requires changing the entire concept of a
> > device node.  How do you link an inode on a disk to an in-memory
> > structure that's created anew each boot?  Pointers certainly wouldn't
> > work.
> 
>   You need devfs before you can completely remove major numbers.  Use the
> permissions of the file of the same name as the device on the mount point
> (and do not allow access if it doesn't exist).  Being able to walk the
> device tree should make implementation of this fairly easy.
> 
> Matthew Orgass
> darkstar@pgh.net
> 
> 
> 
> 
> 
>