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
attached!
> 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 ?
scsidev?
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.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html