--Currently, Linux uses special files, sorted by major/minor numbers, to do device specific interfacing, and provide standard services. This approach has a number of caveats, and I think it would be best to design a new system. Until all the current Linux applications are converted, you could easily provide a backwards compatibility option in the kernel.
My plan for a new /dev hierarchy is as follows: In the /dev dir, backwards compatible inodes and device names would exist (like /dev/hda, or /dev/ttyS0) as they do now, but in a more dynamic fashion (like procfs).
Under /dev, subdirectories that classify the devices in the system logically, instead of physically (again, like procfs). Procfs, for example, has some important information about the system in general in the root dir and special subdirectories (like net). It also has logical subdirectories for active programs, the directories named after a programs PID. For example, /proc/1/ is init (unless your system is somehow running without init :-))
>From my system: lrwx------ 1 root root 0 Oct 20 23:04 exe -> /sbin/init zephyr:/proc/1#
This logical abstraction is very helpful for finding out information about the state of a process, its location, and allows for hooks to control it. The /dev hierarchy could benefit a great deal from a similar setup.
Currently, /dev/hd[letter] is a block device on the IDE chain. This forces the end user to deal with different devices (CDROM drives and HDs, for example) in a similar fashion. Under my proposed /dev organization, a /dev/hd[letter] link could be provided for backwards compatibility, but a better way of getting information about the device would be provided.
My directory naming idea: /dev/device [class|type]/device [name|logical number]/
Example: Let's say that under the old structure, /dev/hdb was an ATAPI CDROM drive. Under my proposed structure, the logical place for the CDROM would be: /dev/cdrom/atapi/ Whereas the physical mapping would be in: /dev/ide0/device1/
This would allow you to quickly find the device knowing either its physical connection (similar to /dev now), or its logical connection (dissimilar to /dev now). For a general purpose bus like SCSI or USB, the logical mapping is more important. Under the current system, mapping up to 127 USB devices to /dev entries would be, to say the least, hellish. Take into account the fact that USB is very dynamic, and you'll quickly find that using a static major/minor numbers is not workable at all. This is where the logical mapping to device classes provides a solution. For a bus like SCSI, which has multiple LUNs, as well as device numbers, the extended physical system provides a better base on which to build the logical mapping. The logical mapping would be built out of the physical mapping, as well as the backwards compatible /dev entries. This could be managed by a userland daemon, provided with the proper info from kernel hooks. It could become a daemon similar to kswapd or kflushd in terms of how it works with the system.
Given this new structure, things like a daemon to automount CDROMs for desktop users, or other "user friendliness" things could easily be designed. It would also be more extensible, flexible, and should meet the needs of users, both enterprise and desktop.
As an extra level of design (see credit for it below), would be a new way of interfacing with the devices. One file in the logical device directory could contain an interface for the memory of the device (useful for video cards, etc), a file to provide backwards compatible ioctl interfaces, and some control files. Under procfs, for example:
zephyr:/proc/1# ls -l total 0 -r--r--r-- 1 root root 0 Oct 20 23:29 cmdline lrwx------ 1 root root 0 Oct 20 23:29 cwd -> / -r-------- 1 root root 0 Oct 20 23:29 environ lrwx------ 1 root root 0 Oct 20 23:29 exe -> /sbin/init dr-x------ 2 root root 0 Oct 20 23:29 fd pr--r--r-- 1 root root 0 Oct 20 23:29 maps -rw------- 1 root root 0 Oct 20 23:29 mem lrwx------ 1 root root 0 Oct 20 23:29 root -> / -r--r--r-- 1 root root 0 Oct 20 23:29 stat -r--r--r-- 1 root root 0 Oct 20 23:29 statm -r--r--r-- 1 root root 0 Oct 20 23:29 status
Memory access, fds, environment, cwd for the program, etc. A similar interface for devices would (hopefully) decrease the complexity of programs that work with them.
>From Kernel Traffic issue #3, released 1999/01/28: "Aaron Denney even suggested, "Instead of ioctls I would actually prefer something akin to to the plan 9 model where each device is actually a directory with two files: a data file and a control file. Instead of opening the device and calling ioctls you would instead open the control channel and read() and write() messages.""
The idea is his, but I think it's a good one.
--If you have any comments, please feel free to say them. If you have flames, OTOH, I'd rather you calm down, and actually debate the flaws in these ideas with a cool head. These are only a bunch of ideas I've written up into a document, and has no bearing on what goes into the kernel (Hello, Linus ;-))
-- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!- 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/