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/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:21 EST