TT> 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.
TT> Sounds like the desrcription of what kerneld was supposed to give
TT> the kernel that I read a couple of years back when I first started
TT> with linux. This whole argument just seems to go round in a circle
TT> over and over again.
TT> No, there's a big difference. The problem with kerneld is that the
TT> kernel had to wait for the user-space daemon to respond before it could
TT> complete some action, such as opening a device, reference some new
TT> network protocol family, touch the PPP or SLIP driver, etc.
1. And now kernel should wait for modprobe to respond :-) modprobe is not in
kernel anyway (and does not belond there IMO).
2. How about accessing of /dev/printer/0 when printed module is NOT in memory
and so /dev/printer/0 is NOT there ?
TT> This turns out to be a bad idea, or at least very hard to get right,
TT> since you have to handle the cases where kerneld is swapped out, or can't
TT> respond in time, etc. Blocking a kernel-space execution path while you
TT> wait for a user-space process to respond is an invitation to deadlock.
But I can not see how kmod changed it: you still should wait for vfat.o to
be loaded by modprobe before mount() can be completed...
TT> The difference here is that what we're providing is a unified scheme by
TT> which the kernel *notifies* a user-space process that some new device
TT> has appeared on the scene. It's a one-way communication, with no requirement
TT> that kernel code wait for the user-space process to do whatever it needs to
TT> do.
When someone tries to access device for which module is not loaded kernel code
SHOULD wait for the user-space process to answer "which module should be loaded
for this device to appear in /dev". No, it's two-way process :-(
TT> The user-space daemon can ignore the event; it
TT> can create a node in /dev; it can initiate a GUI dialog box asking the
TT> user what how some new device should be configured; it can play "God
TT> Save the Queen" in three-part harmony using the multimedia speakers.
TT> It's completely up to user-space daemon, so it's therefore much more
TT> flexible than a kernel-only devfs scheme.
Unfortunatelly it's not so: you CAN do thing with user-space daemon not even
imaginable with kernel-only devfs but you also CAN NOT do some things already
done in Richard's devfs.
TT> From: Khimenko Victor <khim@sch57.msk.ru>
TT> Date: Sat, 9 Oct 1999
TT> Great. Such problems should be and can be fixed before devfs will be
TT> accepted (in 2.5.x -- it's to late for 2.3.x) even if they are not
TT> trivial. But looks like you are the only one who cares about
TT> technical problems with devfs and not political ones :-/ All other
TT> folks (including Theodore Y. Ts'o and H. Peter Anvin) object against
TT> devfs IDEA, not against IMPLEMENTATION.
TT> I'm all in favor of the IDEA of a dynamic /dev directory. What I'm
TT> against is the IMPLEMENTATION that is devfs.
IDEA behind of devfs is NOT IDEA of a dynamic /dev directory. It's idea that
/dev should be what name implies: direct link to device drivers. That is
without any indirect major/minor numbers and such.
TT> You are right where you say that part of the problem with devfs is that
TT> there's a huge pile of different changes all lumped into one patch. In
TT> no particular order, there is:
TT> * A standard interface which is used by devices to register the
TT> existence of new device nodes
TT> * A way of maintaining this information in a tree-like structure
TT> * Patches to change over from a (major, minor) device number
TT> scheme to a name-based scheme.
TT> * A /proc-like filesystem
TT> Because there are so many things intertwined into one patch, it makes it
TT> difficult to talk about it and reason about it, even for advocates of
TT> devfs. The folks who claim that "you don't have to use devfs"
TT> conveniently forget about the ultimate goal of Richard Gooch's to get
TT> rid of major and minor device numbers. And, the folks who argue that
TT> the patch is good because it nukes major and minor devices are
TT> contradicting those who say "you don't have to use devfs". When you add
TT> to this Alex Viro's observation that you can't mount devfs in more than
TT> one place, the fact that you need selected devices in places other than
TT> /dev (in ~ftp/dev to anonymous FTP work, for example) shows us that the
TT> patch simply isn't ready for prime-time, and so because it's one whole
TT> gigantic lump, the whole patch gets rejected.
TT> A patch which only did the first, and maintained the information in a
TT> flat linked list (the tree structure is as part of the name is a policy
TT> that doesn't belong in the kernel; let the user-space daemon or the
TT> separate devfs module take care of that) would likely have a much better
TT> chance of being accepted.
Hmm. What'll be registered in such a list ? IMO some "default" name of device
SHOULD be supplied by device driver. So when you got driver for brand new
device for which there are no information in userspace daemon such device
still can be used somehow (even if name for such device will be ugly). Or that
or each driver should come with some configuration file for every possible
userspace daemon. BTW HOW userspace daemon should distinguish different drivers
if there are neither major/minor numbers nor names ? If such names should
appear in /dev without modifications is other story completely...
TT> In any case, we're in feature freeze at this point, so this flame-fest
TT> is a bit of a waste of everyone's time anyway. But as a path forward,
TT> this is probably the best compromise and way to move forward. We may
TT> still need to design a way for the kernel to talk to the user-mode
TT> daemon, so that it's flexible enough to handle USB and whatever future
TT> plug-n-pray buses come upon the scene, but that shouldn't be too
TT> difficult, compared to the difficulties we've had coming to consensus.
We should support not only brand-new plug-n-pray buses but also old devices
like non IEEE whateveer-conforming printers (or IEEE-whatever conforming
printers turned off while system bootup :-) printers and such. Where you just
have no information about device before user first time tries to access it.
TT> Then folks who like devfs sans a user-mode daemon can have much simpler
TT> patches that do just that, and people who like to have a more
TT> fully-featured user-mode daemon can do things that way. At that point,
TT> though, I hope it will become clear to everyone that it's possible to
TT> have a dynamic /dev directory *without* having the devfs component, and
TT> folks will come to see that by having the minimal kernel hooks to allow
TT> a user-space daemon, the result is cleaner, and in the long-run, allows
TT> us the flexibility to make the system much easier for the user to use.
Looks like a plan :-)
-
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/