> ["H. Peter Anvin" <hpa@transmeta.com>]
> > David Weinehall wrote:
> > >
> > > Oh, and have you actually ever tried a system running devfs (such as a
> > > kernel patched with Richard Gooch' patch, or a Solaris-system), or?
> > >
> > > Hmmm. If USB isn't enough to convince, think about USB2 (128 devices/bus
> > > if I'm not all wrong), FireWire, FibreChannel, SCSI-III, etc. Sooner or
> > > later we need a solution to the problem with devices. And devfs is a very
> > > good, thought-through, proven to work (been used in Solaris for many
> > > years) and backward-compatible solution. And it's available now.
> >
> > Solaris does *not* use devfs; the /devices tree is an on-disk device
> > node tree which is constructed at initialization time, and it is
> > persistent. A much better solution, IMNSHO.
>
> How exactly does such a solution work with hot-plugable devices?
> Some daemon that gets informed of devices appearing and disappearing?
> I don't think I'm being unreasonable in thinking that when a device
> is added to the system it should instantly be usable. That's kind of
> the point of dynamic busses, no?
I'll start by stating that I'm a strong advocate of the daemon approach.
I envision it working in a manner similar to the way pcmcia-cs works --
that is, a daemon gets informed of device attach/detach, and then (based
on rules supplied by a configuration file(s) ) executes whatever
configuration is necessary to make the device available (or clean up after
it).
While there is some lag between the insertion event and when the device
becomes available, it's pretty minimal for most things. Some delay is
unavoidable -- after all, the device must be initialized (and that takes
some non-zero amount of time).
I think (and I know this was a hotly debated point in the past, but since
it's come up again, I'll say this again) that it's important for the
kernel not to force it's own policy on devices. Consider the attachment
of a USB mouse. Do I want /dev/mouse to point to that device? Good
question. Depending on who I am and what else I have attached to the
system, the answer varies. I can also imagine the case where I have
several USB mass storage devices which I want to always get the same sd*
assignment, depending not on attachment order, but on their contents.
Given the supposition of a daemon-centric solution, then the requirements
to implement such a solution are twofold: (1) a place where USB devices
can be accessed based on device number or some other USB-centric
designation, and (2) a place where we can store some static information
(ownership, permissions, etc.).
#1 might be providable by a /proc/bus/usb/dev tree... #2 might come from
traditional /dev/, or some other source.
I think I should point out that some type of user-space
notification/configuration system is necessary. Specifically, there are
system devices which are not represented under the /dev/ structure (i.e.
Ethernet, which I'm working on) which will need configuration upon
insertion. In the case of an Ethernet device, it needs at least to be
given an IP or select DHCP/BOOTP for configuration... perhaps it needs to
be disabled instead. Regardless, we need user-space notification for
this, and a standard way to do this for USB devices (and perhaps for all
plug-and-play devices) would be a good thing to design in to the kernel
now.
Matt dharm
-- Matthew Dharm InterNIC: MDD94 Engineer Cell: (619) 890-6943 Home: mdharm@one-eyed-alien.net Home: (858) 689-1908 Beep: page-matt@one-eyed-alien.net Beep: (858) 621-8155I want my GPFs!!! -- Stef User Friendly, 11/9/1998
- 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/