On Sun, Oct 10, 1999 at 12:30:06AM +1000, Nathan Hand wrote:
> Devfs as a filesystem doesn't do enough. You still need a user space
> daemon to do more complex things. For example, plugging in a hotswap
> isdn card shouldn't just create /dev/ppp, it should also fire up the
> ifconfig and pppd processes. There are other (better) examples.
>
> And once you admit you need a user space daemon, then you can accept
> that you don't *need* devfs as a filesystem. You can achieve most of
> devfs's functionality using a user space daemon. I particularly like
> your idea of select/poll on /proc/devices.
Sounds like the desrcription of what kerneld was supposed to give
the kernel that I read a couple of years back when I first started
with linux. This whole argument just seems to go round in a circle
over and over again.
No, there's a big difference. The problem with kerneld is that the
kernel had to wait for the user-space daemon to respond before it could
complete some action, such as opening a device, reference some new
network protocol family, touch the PPP or SLIP driver, etc. This turns
out to be a bad idea, or at least very hard to get right, since you have
to handle the cases where kerneld is swapped out, or can't respond in
time, etc. Blocking a kernel-space execution path while you wait for a
user-space process to respond is an invitation to deadlock.
The difference here is that what we're providing is a unified scheme by
which the kernel *notifies* a user-space process that some new device
has appeared on the scene. It's a one-way communication, with no
requirement that kernel code wait for the user-space process to do
whatever it needs to do. The user-space daemon can ignore the event; it
can create a node in /dev; it can initiate a GUI dialog box asking the
user what how some new device should be configured; it can play "God
Save the Queen" in three-part harmony using the multimedia speakers.
It's completely up to user-space daemon, so it's therefore much more
flexible than a kernel-only devfs scheme.
From: Khimenko Victor <khim@sch57.msk.ru>
Date: Sat, 9 Oct 1999
Great. Such problems should be and can be fixed before devfs will be
accepted (in 2.5.x -- it's to late for 2.3.x) even if they are not
trivial. But looks like you are the only one who cares about
technical problems with devfs and not political ones :-/ All other
folks (including Theodore Y. Ts'o and H. Peter Anvin) object against
devfs IDEA, not against IMPLEMENTATION.
I'm all in favor of the IDEA of a dynamic /dev directory. What I'm
against is the IMPLEMENTATION that is devfs.
You are right where you say that part of the problem with devfs is that
there's a huge pile of different changes all lumped into one patch. In
no particular order, there is:
* A standard interface which is used by devices to register the
existence of new device nodes
* A way of maintaining this information in a tree-like structure
* Patches to change over from a (major, minor) device number
scheme to a name-based scheme.
* A /proc-like filesystem
Because there are so many things intertwined into one patch, it makes it
difficult to talk about it and reason about it, even for advocates of
devfs. The folks who claim that "you don't have to use devfs"
conveniently forget about the ultimate goal of Richard Gooch's to get
rid of major and minor device numbers. And, the folks who argue that
the patch is good because it nukes major and minor devices are
contradicting those who say "you don't have to use devfs". When you add
to this Alex Viro's observation that you can't mount devfs in more than
one place, the fact that you need selected devices in places other than
/dev (in ~ftp/dev to anonymous FTP work, for example) shows us that the
patch simply isn't ready for prime-time, and so because it's one whole
gigantic lump, the whole patch gets rejected.
A patch which only did the first, and maintained the information in a
flat linked list (the tree structure is as part of the name is a policy
that doesn't belong in the kernel; let the user-space daemon or the
separate devfs module take care of that) would likely have a much better
chance of being accepted.
In any case, we're in feature freeze at this point, so this flame-fest
is a bit of a waste of everyone's time anyway. But as a path forward,
this is probably the best compromise and way to move forward. We may
still need to design a way for the kernel to talk to the user-mode
daemon, so that it's flexible enough to handle USB and whatever future
plug-n-pray buses come upon the scene, but that shouldn't be too
difficult, compared to the difficulties we've had coming to consensus.
Then folks who like devfs sans a user-mode daemon can have much simpler
patches that do just that, and people who like to have a more
fully-featured user-mode daemon can do things that way. At that point,
though, I hope it will become clear to everyone that it's possible to
have a dynamic /dev directory *without* having the devfs component, and
folks will come to see that by having the minimal kernel hooks to allow
a user-space daemon, the result is cleaner, and in the long-run, allows
us the flexibility to make the system much easier for the user to use.
- Ted
-
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/