[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Andreas Jellinghaus writes:
> >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.

Bad luck if you want your root FS to be isofs, NTFS (HPFS?) or
something like that.
The scheme you mention is basically scsidev. It doesn't address all
the other possible device nodes you might have. I don't see that
information coming from the boot logs or from /proc. To put that
information into /proc requires a lot of hacking of drivers.

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

Maybe I don't want to see the zip drive entries when it's not

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


And another problem: when we go to larger kdev_t, *each* open(2) of a
device node will require a search through a major device table (not a
simple index like we have now). Devfs also avoids that search.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:43    [W:0.193 / U:2.800 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site