Johannes Erdfelt <jerdfelt@valinux.com> said:
> 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.
That is extremely broken in many people's eyes... and for "normal" setups
(not half a dozen mice that are being swapped around all the time), there
is no need I see for devices changing names anyway. Many cases where it
happens and also matters are handled by mounting by UUID anyway.
> Having a userspace daemon keeping track of this is a MUST.
Agreed.
> Keeping it in the filesystem is not enough.
Agreed.
And the userspace daemon modifies a normal, on-disk filesystem to reflect
new devices as they appear, the user chmod(1)s and chown(1)s them to her
heart's content. No virtual filesystem needed at all.
I've been told that this scenario doesn't solve the problems devfs is
supposed to solve, but nobody has been able to explain to me exactly what
those unsolvable problems are, and why they are problems worthy of solution
in the first place.
How do you record devices in the filesystem is up to you, it doesn't have
to be via major/minor numbers. Any unique ID will do. There is plenty of
unused space in an inode used for a device right now. So the "no
major/minor" argument doesn't cut it either. Or am I overlooking something
fundamental here?
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- 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:26 EST