From: Linus Torvalds <torvalds@transmeta.com>
> Ted is on some experimental drugs, and he's much better now, I'm told.
No, I just stopped arguing about it because the argument was going
nowhere, and it was just wasting bandwidth on linux-kernel. I also made
the mistake of beliving Linus's claim that we were in feature freeze. :-)
Date: Thu, 13 Apr 2000 08:03:23 -0700 (PDT)
From: Linus Torvalds <torvalds@transmeta.com>
> > What do you buy by having a separate backing store (aka
> > "underlying FS")?
> > Not much.
>
> Only the difference between "utterly broken" and "working" for devfs
Wrong. If you have to have backing store, THEN it is broken. That shows
that devfs doesn't actually buy you anything, and playing with a virtual
filesystem is not worth it. Because there are no advantages.
Exactly. So, why do we need to have backing store? Because there's all
sorts of information that needs to be saved. Users want to be able to
chmod the device modes, and it's non-intuitive that they aren't
persistent across (a) reboots, and (b) device removals and
re-insertions. You can try to save that state someplace, but at that
point, you start having to deal with some kind of user-space protocol
that has to be running. But at that point, you have to ask the question
why have a user-space daemon save state when that's what filesystems are
supposed to do, and do well?
You end up either end up with a gross kludge, like tar on shutdown ---
which doesn't solve the device removal stage, unless you have devfsd
block the kernel from doing a device removal, run tar to save the state,
and then allow the kernel to continue the device removal (which would be
a disaster).
OR, (B) you end up writing the equivalent of a little userfs protocol
where you have to have a user daemon save the state on a device removal
and shutdown. This sorta works, but people will have there differences
about whether this is clean. I think it's ugly as all heck, but some
people seem to loke it.
OR, (C) you try to do what Richard's been doing, which is trying to
have it both ways. Both have the virtual filesystem, *and* try to store
the inode information into the layer below, so it can be backed by a
real filesystem, without needing userspace help.
This is really all about moving the dirt around. You can sweep it under
the carpet, but the dirt is still going to be there. The different
solutions simply sweep it under different corners of the rug, and with
the lump in some cases better distributed than others. :-)
Here are other problems that devfs brings up. There are cases where you
want to have entries in /dev that don't correspond to actual loaded and
registered devices. For example, you might want to have a device driver
which is loaded on demand. No problem, you create the device file in
/dev, and when you access the device file, the kernel will automatically
try to load the module corresponding to the file. But with devfs, you
can't do that, since the device hasn't been loaded yet.
Another case is if you have some dumb ISA bus serial ports.
(i.e. /dev/ttyS4, /dev/ttyS5, etc). In some cases, you could have as
many as 32 of them. Unfortunately, with the ISA bus, there's no way to
autodetect such cards; you have to manually configure them. And, there
are a lot of these cards, and the ports can be anywhere in the I/O
space, which means you don't want to preload the kernel with a huge
number of predefined addresses fixed at compile-time, and it would be a
massive pain to pass IRQ and port information in on the boot command
line each time you want to boot.
Hence, the recommended configuration is to use the setserial command
(usually driven out of an rc.d file) to configure the serial ports.
Again, the problem is that the ports have to be configured before they
can be registered, but in devfs, the device nodes aren't created until
you register the device. Another chicken-and-egg problem.
You can kludge around these problems using devfsd, but at what point are
all of the kludges (for persistence, to handle these chicken and egg
cases, etc.) start adding up to the point where it's no better, and
perhaps worse, than the problems that it ostensibly was trying to fix?
That's not to say that we don't need a better solution for these
problems; it's just that devfs isn't it. At least IMHO.
- 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/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:25 EST