Messages in this thread | | | From | "Anthony Barbachan" <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) | Date | Thu, 6 Aug 1998 04:55:12 -0400 |
| |
This definitely has some useful qualities, however some things do not need to be changed over to new names. The IDE devices comes immediately to mind. There can only be 8 EIDE devices on a system and the device names for EIDE and each device name is already is mapped to a specific drive location. (ex. /dev/hdc = Second Master) (Note: /dev/hda is much, much simpler and understandable than /dev/IDE/hd/c0b0t0u0, especially considering that c0b0t0u0 is completely unnecessary when c0d0 would do (c = chain, d = disk), if not /dev/IDE/[0-7]. There is also only 4 possible standard serial ports and 3 possible standard parallel ports. Also only two possible floppies. And if I remember correctly the floppies and serial ports are also mapped to specific locations. (ex. /dev/fd0 = A: Drive, (Perhaps parallel ports should be as well?)) Furthermore there are many other devices which can only be installed one or a few to a system. These are also probably the most common devices found on most Linux users' systems. Since this is the case it is my opinion that at least these common, limited, devices should continue to be /dev/[devicename]. And if devfs takes over the /dev directory these devices still do not have to exist in a file system (saving a little space) and should still be able to avoid the device number limitation problem. This has the added benefit that it help maintain backward compatibility for the majority, if not vast majority, of Linux users. Only changing what needs to be changed, especially SCSI/ USB/multiport adapters/etc which can have a large number of devices. As far as being able to scan a devfs /dev and figuring out which devices exist and which do not, what happens in largely modularized systems like most of mine, which have much of the kernel in auto-loading/unloading modules? Since the most popular distribution also seam to make heavy use of auto-loading/unloading modules this might be a widespread problem/oddity. Perhaps a device's, apparent, existence (due to a loaded driver) should be indicated in a different manner? Maybe through using one of the unused permission bits, or an alternate "known present" devices proc entry like /proc/devices/. Of if possible, only having devices exist as entries in the directory with no actual disk space allocated to it. But this is probably only doable in the filesystem code. (Note: this could be good for ext3.) Basically I think this is generally a good idea, but the changes to device names should be limited only to those devices that need the name change like SCSI/future USB devices/multiports/etc. EIDE/floppies/serial ports/parallel ports/etc do not need a name change and should be left as is. Super long device names easily become verbosely cryptic and should be avoided whenever possible (ex. /dev/IDE/hd/c0b0t0u0).
> >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. > >I've heard the suggestion that you use initrd to populate /dev >automagically. IMHO that is simply silly. Firstly it takes time to >create all those inodes (for devices you have). When you shut down you >should probably remove those inodes. *This* is cleaner than devfs??? >If people want to automagically populate /dev from userspace, it >requires information from the kernel (current boot logs do not provide >sufficient information). Making the boot logs spit out information for >every device file available is no good: the boot logs will be too >cluttered. Creating a special /proc entry is better, but still >requires hacking lots of drivers and then we have the inevitable >problem where the format changes so the userspace tool has to be >changed. Yuk, yuk, yuk. > >I would dearly like to hear practical solutions to *all* the issues I >raise in the devfs FAQ. Every time this discussion comes up, I hear a >selective subset of the issues which conveniently ignores all the >other issues that devfs addresses. This then leaves some people with >the feeling that "devfs is flawed, ugly and/or unnecessary", because >they haven't thought about all the issues I raise in the FAQ. > > 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 >
- 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
| |