Re: Suggested dual human/binary interface for proc/devfs

From: H. Peter Anvin (hpa@transmeta.com)
Date: Thu Apr 13 2000 - 15:18:00 EST


Linus Torvalds wrote:
>
> On 13 Apr 2000, Kjetil Torgrim Homme wrote:
> >
> > To make devfs really useful the permissions need to be set on a higher
> > level, algorithmically and dynamically. That is, a user space device
> > manager where you can specify _general_ rules like "members of the
> > backup filegroup shall have read access to all storage devices".
>
> Exactly. This is the kind of thing that makes devfs worth it. Together
> with some way of specifying these things for the whole network (I wasn't
> kidding when I mentioned NIS) it actually gives system administrators
> something new. And it makes for more than just a regular /dev on a regular
> filesystem.
>

This seems to me to be better handled with ACLs that can contain
groups. You have an ACL for your storage devices (sharing ACLs is
pretty much a requirement for storage-management reasons, on *any*
filesystem) and have your backup filegroup as a conventional Unix group.

We need ACLs in general, not just for devices.

> Imagine devfs together with network block devices - you could quite
> transparently handle local/non-local disks etc, without the user even
> knowing. And with the sysadmin being able to change what /dev/hda is
> without having to even log onto the machine in question..
>
> [ Yes, that example probably sucks. Don't even bother showing how stupid
> it is. I'm more trying to get the mindset here. ]

Umm... you better have the user (meaning sysadmin here) knowing... I
wouldn't want to find out that I accidentally just erased a file server
half-way across the building because it was detected earlier in the
sequence... The end user shouldn't see this stuff at all, as it is all
handled by the mount abstraction.

I know you said this is a bad example, but it provided excellent grounds
for my standard 2 complains: the bindings of properties, permissions,
yadda yadda requires persistent state in some form. I happen to believe
that the abstraction of seeing it as a filesystem (/dev) is nice, rather
than an obscure configuration file, but I can understand the filesystem
metaphor doesn't apply well in a hot-plug world.

The second complaint is that devfs is a solution in search of a
problem. It doesn't solve the problem above (it still needs the
user-space daemon), but it still wants to keep an enumeration of all
device nodes in unswappable kernel memory rather than on cheap disk.

        -hpa

-
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:22 EST