The DEVFS supporters keep saying that devfs creates device entries on the
fly and that this simplifies use.
Ok. First, I like this feature. However does this feature really
require DEVFS? Couldn't the currently device registration code be modified
to automatically create missing device entries? Might this not be a
simpiler and more backwardly compatable approach to acheive this feature?
The DEVFS supporters keep touting that the SCSI naming problem is resolved
by DEVFS.
Ok. I like being able to address SCSI devices by their target ID's too.
However wouldn't it be simplier to just modify the SCSI drive,tape,CDROM,etc
drivers to have their devices hardcoded to /dev/scsi/c0t0d0 and so on?
Furthermore I think being able to mount volumes by volume labels is a
better solution to the SCSI reordering problem. All the main filesystems
already have volume labels, ext2, FAT, VFAT, FAT32, iso9660 so for most
setups this solution works perfectly and also happens to be more
administrator friendly. In reality only the CD's wouldn't be able to use
this very well since they are removable, but in that case perhaps mounting
could be allowed by the CDROM model or serial number. In any case the drive
reordering problem is more likely to be a problem when mounting drive
partitions not CDROM's since that could be easily fixed after bootup.
By the way the /dev/scsi/c0... setup is not optimal for direct
addressing either as a controller change or addition can still mess things
up badly. A better solution may be for SCSI drivers to make a directory
under /dev == to the driver name plus an incrimenting number such as
/dev/aic7xxx0 and then make device files per existing device under that new
directory such as t0, t1, t2.
DEVFS removes the clutter from /dev.
Well if the device registration code automatically created device file
when they were missing then you could literally do a rm /dev/* and reboot.
Upon bootup and future use only those devices detected would be created.
After their creation permissions could be adjusted and preserved just like
in the traditional setup.
Automatic notification of when devices are added and removed.
Like the features listed above, I like this feature too. However does
this really require an all or nothing approach? The pro-devfs arguments
seam to say if you want one or more of these features you must take all of
devfs. What if I wanted one or more of these features more not the entire
devfs running on my system?
Assorted questions.
Do we really want an external deamon handling something so OS important
and specific as device handling? Doesn't this add a memory footprint and
well as CPU usage to low memory systems, embedded ones, etc? What if Joe
User, who happen to run his own single user Linux box on low end hardware,
disables the loading of devd to save memory and reboots and now his system
isn't running this now necesary deamon?
On the limitation of the the 16bit major and minor numbers and it being
solved by devfs, what is wrong with moving to a 32bit major and minor number
instead. Beside which are we really in danger of running out of major and
minor numbers? Each has 65K of distinct possibilities and when combined
that goes to 4G of distinct devices.
Even though this isn't brought up much I remember before people saying
that devfs says disk space used by device files. Couldn't our future
filesystem be modified to store device files more efficiently?
Do we really want two completely different means of handling devices
under Linux? And also is the need really that great to necessitate a move
away from the traditional means of handling files through standard device
files?
Does the world have to be changed to use devfs? For example does the
need for SCSI and USB for the thousands of connected devices for direct
addressing and handling require that everything else also be changed?
Floppies, Parallel Ports, Serial Ports, IDE devices, and many more all
already are directly addressed in the current setup and also happen to be
limited in number by design. None of these need changing (at least not
massive changing, maybe a small addition here and there) and will not in the
foreseeable future, so why mess with them. They already work and work well.
-
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.tux.org/lkml/