Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

[Andreas Jellinghaus]

>The thing that really motivated me to start it was the horrible SCSI
>disc naming scheme (take out one ID and play musical chairs with your
>device names) and the fact that you have to have zillions of inodes to
>support all the possible SCSI discs you could have. Right now you need
>256 inodes in /dev to ensure you can use and of the possible discs and
>partitions. Later as we support more SCSI discs, the number of inodes
>will have to be increased. Distributions will have to ship systems
>with /dev having thousands upon thousands of inodes. This is a
>joke. Apart from being incredibly ugly (having a huge /dev), having
>lots of inodes means that directory searches are quite slow.

you don't need /dev to mount the root filesystem. you don't need /dev to
mount the proc filesystem. and then you can scan the proc filesystem for
existing devices, and create the necessary inodes (or remove unnecessary if
you like). so far no need to have something in the kernel.

>Firstly it takes time to create all those inodes (for devices you have). When
>you shut down you should probably remove those inodes. 

the problem with current /dev :
 - no easy way to remove unnecessary inodes
 - no easy way to add required inodes (and only these).

reading kernel tables of what hardware exists via /proc filesystem
will allow to change this. people don't change there hardware so often, that
they need to create or delete inodes every day. 

you can keep that few devices for your zip drive in /dev, even if it's not
attached. tomorrow you will use them again, so don't remove and add them.

the big problem i see : people realy need scsi devices that reflect the 
controller/bus/lun structure. 

has anybody an idea how to manage that without devfs ?

andreas