On Fri, Apr 14, 2000, Theodore Y. Ts'o <tytso@MIT.EDU> wrote:
> 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?
That is exactly the biggest weakness for keeping permissions/ownership
in the filesystem.
And here is the reason: Hot Swap and Plug and Play devices.
They don't keep the same names from reboot to reboot. Heck, you unplug
it and plug it back in and it can have a different name.
Having a userspace daemon keeping track of this is a MUST.
Keeping it in the filesystem is not enough.
> 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).
I think the tar solution is not enough. It essentially duplicates the
amount of functionality storing the state in the filesystem has.
Unfortunately, that's not enough functionality.
> 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.
Do you have any other ideas for tracking Hot Swap and Plug and Play
devices?
No one has come up with an alternative solution which will work yet.
Doesn't mean there isn't one tho.
> 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.
Unfortunately this isn't sufficient as well. I'd like to explain this to
Richard, but he's been very slow about responding to my emails regarding
devfs and Hot Swap/Plug and Play devices.
If a userspace daemon must track devices (like I asserted above), I see
no reason the have the kernel bother with having to change the
permissions when userspace can do it fine.
> 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. :-)
Got to keep it somewhere.
The difference now is that you require lots of policy and smarts to track
it and you know where that belongs, userspace.
> 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.
You can do it with devfsd.
> 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.
Perhaps configuring the devices is the problem here, not registering
them?
> 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, no offence (especially since I work with you), but you are not
helping the problem. Many people have been saying "devfs is not the
solution", but no one has offered up an alternative solution which
solve all of the problems.
With devfs and devfsd you can solve them. They may not be "pretty" to
some, but it actually works as opposed to now.
All I want is a solution. It doesn't have to be devfs, it can be
anything, but until someone comes up with a better solution (hell, any
other solution), I'm going to advocate devfs.
JE
-
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