![[LWN Logo]](/images/lwn.banner.gif)
To: linux-kernel@vger.rutgers.edu From: jmcmullan@linuxcare.com Subject: Re: devfs - the missing link Date: 22 May 2000 05:37:03 GMT James <james@amethyst.nurealm.net> wrote: > I read through Neil Brown's reflections on the devfs, picked up by the Linux > Weekly News. I have some thoughts to share, somewhat naive, as I haven't > been following the devfs debate very closely. > > [Really-big-snip-of-stuff-that-should-go-into-a-whitepaper-or-something] <RANT TIME="latenight" MODE="ramble"> James brings up a lot of interesting observations, all of which seem to clustered around a few main points: *) UNIX traditions: Why do we keep hanging on? *) What do device drivers give the OS, from an architectural point of view? *) Can we design a device driver structure that is architecturally consistient? ------------------------------------------- UNIX traditions: Why do we keep hanging on? ------------------------------------------- The primary UNIX tradition is "Everything's a File(tm)". This architectural guideline has helped UNIX stay (internally) pretty clean for the last 25 years. We should stay with that principle, but we should look at what UNIX has gathered to itself over the years, as we may want to ``prune the tree'' for Linux 3.0. The UNIX device major/minor system has been around since the early 80s, if not earlier. The major/minor system was originally designed to function in exactly the way James envisions: class::instance of class. The major number was the device driver identifier, and the minor number was the particular hardware instance. This system was designed for, and worked well on, minicomputers and mainframes with a) limited device types b) few instances per type and c) limited, and propriteary, future devices. However, the PC class of system fails all three of the original design constraints. I find it amazing that the major/minor system has lasted this long. As for network devices, we have Berkely Unix to thank. Although the premise of a separate namespace for network devices was arguably an excellent move at the time (don't need to worry about namespace collision in /dev, no need to write a new filesystem - and at that time many UNIX systems didn't have a VFS-style layer), it is flawed by its diversion from the UNIX ideal - "Everything's a File(tm)" Network devices, the network sockets, etc. were pushed into a namespace that could not be inspeced from userspace without special tools such as ifconfig, route, netstat, etc. Call me SysV, but I am a firm believer in presenting the network namespace in the UNIX tradition. ------------------------------------------------------------------------ What do device drivers give the OS, from an architectural point of view? ------------------------------------------------------------------------ Device drivers should present, through a consitient API (my preference being a filesystem) everything that an application needs to use the device in a manner that is consistient, and safe to the integrity of the system. Certain things are crucial for a device driver application API (ie, a filesystem) to present: * Topology-based lookup - What devices are on USB bus 2? * Superclass-based lookup - What block devices are online? * Class-based lookup - What IDE devices are online? * Instance-based lookup - Where is IDE0 on the bus layout? Also, certain things are crucial for a device driver itself to present: * Access control - Who can do what to this device? * State retreival - What is the hardware's state? * State control - Set the hardware's state. * I/O - Actually USE the device. The phrase that must be in the forefront of your mind when working with devfs, procfs, major/minor, or any other device driver API: Does this system provide a safe and orthoginal system for topology, lookup, access control, and persitience? ---------------------------------------------------------------------------- Can we design a device driver structure that is architecturally consistient? ---------------------------------------------------------------------------- Devfs is an excellent starting point for the change in UNIX, but it is just that - a starting point. It will have it's flaws, as any starting point does. They will be hammered out, and within a short period of time it will be found useful by even the most strident of today's devfs opposition. But that is just one aspect of the problem: exposing namespace via the filesystem. I think it should be extended further, as James suggests, to unifying the configuration and access control of char, block, and network devices as much as possible. There is a need for bus configuration (IRQ, IO, DMA, SCSI ID, etc), physical configuration (DMA speeds, MAC address,etc) and logical configuration (/etc/fstab, IP addresses, etc) Should all of this configuration be consolidated in a uniform format? Yes. Should all of this configuration information be exposed in the filesystem? Again, yes. However, should this configuration information be placed in /etc or /dev, or /devices, or /proc? Should it be in 1 file, 10 files, or 10000? These are the questions we ask ourselves with every procfs/devfs debate - where to store the configurations. Personally, I don't care WHERE we put it - so long as it's ALL IN ONE PLACE. James is right - having to look 10 different places just to find out that ``oh yeah - I use setterm(1) to send the ioctl() to my VT to turn on power management when I'm in the console'' just doesn't make sense - especially since we, the Linux community, have the ability with Linux 3.0 to _drop_ all of the cruft that has gathered in UNIX - and Linux - over the past 25 years. Let's clean up our room, tidy up after ourselves, and give the coders who will come after us a clean slate to work from. Remember - what we architect now is what you'll be coding on till Monday, January 18, 2038 - when you're trying to to make some extra cash for retirement before 2^31 seconds since UNIX Epoc rolls around.... </RANT> -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax jmcmullan@linuxcare.com, http://www.linuxcare.com/ Linuxcare. Support for the revolution. - 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/