Johannes Erdfelt (jerdfelt@valinux.com) writes:
> 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.
True, but every plug-n-pray and hot swap device has *something* that marks it
as unique, else you wouldn't be able to tell what it is. Ethernet cards have
MAC addresses, HD drives have model/serial numbers, etc.
> Having a userspace daemon keeping track of this is a MUST.
Well, at least it's an option - one which I feel better about rather than yet
another thread in the kernel (where, IMO, it doesn't belong).
> > 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.
Hell, Windoze uses the registry to save device states between insertions - if
we can't do better than that, at least we can save the state *somewhere* (and
I sure don't mean another registry!) It makes sense to do it across-the-board,
rather than making every module do their own or throwing it over on cardmgr.
> > 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.
Strange, I keep coming back to Thoreau's comments: "simplify, simplify,
simplify"...
> The difference now is that you require lots of policy and smarts to track
> it and you know where that belongs, userspace.
Agreed. There's enough in the kernel now as it is...
> > 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
I guess I was mistaken when I used to have a four port card in my old 486 box
and Linux found it and configured it just fine. Ted, didn't you do the driver
magic for this?
> 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.
I used to work for Ross Perot (and thenk you for your sympathy!) I learned a
few things from that association, one of them being, if you went to Ross with
a problem, you'd better have a solution and a plan, otherwise he'd boot you
out of his office. Good advice.
-
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