jmcmullan@linuxcare.com said:
> James <james@amethyst.nurealm.net> wrote:
[...]
> 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.
>
[...]
> 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)"
A socket is a file... at least for the program using it. And net devices
are fundamentally different from other stuff in that they are able to
manage lots of conections without any relationships among themselves at the
same time (If there were a relation, a filesystem could do... but they are
streams, much like ttys. Might be handled like virtual ttys are handled
now?)
[...]
> ------------------------------------------------------------------------
> 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?
Why do I have to know where my mouse happens to be connected to the system
today? I don't want to have to care where my disk sits, I want to get at
its contents. Besides, the world seems to be mowing away from "static
device positions" (USB, hotplugging, the huge disk fabrics being discussed
here on and off), so this would just paint us into a corner in some 3 to 5
years, if not earlier.
> * 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?
This is wrong. I want my /home partition, or the tape with yesterday's
backup. Sure, the way to get at them today is through a position (/home is
/dev/hdb3, tape is /dev/st3), but this is not ideal at all. And if stuff
starts moving around, any such scheme is hosed anyway. Can't go in and
clamp the mouse to its USB port until the user (or whatever) reacts to the
presence of the mouse _just there_.
> 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?
And possibly multiple views (i.e., user chrooted or running DOSemu has to
see floppy A, but not the other "floppy" (f.ex. tape) devices; has
read-only access to the tape (get files from backup, don't overwrite),
etc), no access (better even, no idea) of extant hard disks, ...
> ----------------------------------------------------------------------------
> Can we design a device driver structure that is architecturally consistient?
> ----------------------------------------------------------------------------
[...]
> 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.
Thinkful wishing, that one... devices are very fundamentally different in
their management (just look at how many network card drivers, or SCSI
drivers, are in the current kernel). Some share IRQs, others don't. Some
use up IO memory slots, others don't. Some can be read, others can't. Many
can be configured by out-of-band data (f.ex. tty handling), and where this
can be done it is usually completely idiosincratic (it doesn't make sense
to set the baudrate of a disk). And so on. Even after the OS has done it's
magic, they are different enough so that there are ioctls to handle the
remaining differences in a (halfway) sane way that is (reasonably) OS and
physical device independent. Besides, most of this information is something
the user doesn't need to know (even less tweak), except under very, very
special circumstances. A specialized API for this isn't a great burden if
you look at it this way. Sure, could be more consistent, but the underlying
reality just isn't. So this is _hard_.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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