It seems to me that there is exactly one feature of devfs that is
definitively new, useful, and important: Support for hot-plug devices.
But why implement a filesystem just for that?
I propose that we keep /dev as a normal filesystem and create only the
exact thing that we really need: the kernel->user protocol to report
the appearance and disappearance of hot-plug devies.
A daemon that understood such a hot-plug protocol -- call it
"hotplugd" -- would create and remove plain old device nodes in a
plain old /dev directory, thus serving the purpose that devfs is
designed to serve. It could also be configured to execute arbitrary
user-mode code, in the style of PCMCIA's cardmgr, to handle any
additional configuration tasks required (ifconfig, route, etc.).
This approach would meet three current needs:
1. It would provide a missing piece in 2.4's PCMCIA handling --
CardBus devices show up as PCI devices, but there is currently no
mechanism to notify user-space code that PCI devices have come
or gone. In theory, all of the PCMCIA user-mode support could be
handled through hotplugd.
2. It would provide a hook for other non-PCMCIA hot-plug devices that
are currently not well supported, such as docking stations that
show up as PCI bus bridges, IDE controllers, etc.
3. It would finally get the devfs argument off linux-kernel.
(Hey, I can dream, can't I?)
And there's no reason to limit the mechanism to one hotplugd. I can
see specialized ones looking only for specific kinds of devices to be
appearing or disappearing ... not because it couldn't all be handled
through one, but for ease of implementing separate software packages.
In summary, a hot-plug daemon would give us the best of the current
system -- because the current system of /dev nodes would remain
unchanged -- while adding the arbitrary flexibility offered by devfsd.
Opinions? (Now I've asked for it.)
--
Chip Salzenberg - a.k.a. - <chip@valinux.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
but he stepped in a wormhole and had to go in early." // MST3K
-
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 : Sun Apr 30 2000 - 21:00:15 EST