lkml.org 
[lkml]   [1999]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: UUIDs (and devfs and major/minor numbers)
Werner Almesberger writes:
> Disclaimer: I haven't looked at the actual devfs code, but
> considering that there must have been one longish linux-kernel
> thread carefully dissecting every single line of it by now, I've
> worked up enough confidence to voice my opinion anyway ;-)

I get the strong impression that some of the most vocal opponents have
not even bothered to download it, let alone compile it and try it out.
I do actually monitor my ftp logs, you know...

> Richard Gooch wrote:
> > Theodore Y. Ts'o writes:
> >> Well, no, that doesn't work, since there plenty of non-process stuff
> >> which doesn't fit into a devfs mounted in /dev.
> >
> > Such as?
>
> /proc/mounts ?

So is it better to have it under /dev/kernel or /proc ?

Anyway, I'm not arguing for moving /proc/mounts, specifically. But
/proc/mtrr, for example, doesn't belong there. I just put it there
because there wasn't a better place. /dev/cpu/mtrr seems much more
logical.

> > Explain to me how this is different from mounting devfs onto /kernel
> > and using devfsd to populate a disc-based /dev.
>
> I think Ted disagrees with devfs making choices like lumping all
> the, say, IDE CD drivers together, instead of separating them by IDE
> bus.

You mean /dev/ide/bus#/cd/device# as compared to /dev/ide/cd/location#
I assume?

> I guess the real question is whether classifying things by their
> purpose (e.g. "disk") instead of their attachment (e.g. ide0/master
> or isa/busmouse) adds any significant complexity or ambiguity. I
> think in almost every case the classification is already done
> elsewhere, so it probably isn't too much of a problem.

At least in part, devfs reflects the structure of the device
drivers. And that structure makes a lot of sense.

> > But this is a straw-man argument, because it ignores the persistence
> > problem with a dynamic disc-based /dev which is managed with a user
> > space daemon. This is a problem that's been overlooked.
>
> Actually, with devfsd, wouldn't it be easier to have a configuration
> file with a set of rules, a bit like what /dev/MAKEDEV has, but perhaps
> more like a set of chmods executed in sequence, so that you can have
> layered defaults ? E.g.
>
> perm root sys 600 * */* */*/*
> perm root sys 666 null zero full
> perm root disk 660 */disk/*
> ...

Yes, although I think it would be more logical to reverse that order.
In fact you can do this already (noting that it's not optimal, as
you'll get multiple chmod(2) calls, rather doing just one). The
current order is in fact the reverse order you suggest.

Anyway, you're basically agreeing with me that Ted's mutterings about
"persistence hacks" are a straw man.

> Then simply refuse any direct chown/chmod by the user. Once people
> are used to it, they may actually like it better.

Indeed. It's a more efficient way of storing permissions. A few bytes
controls a whole group of entries.

But: disallow chown() by the user? Users can't do that anyway.

> Sorry if I'm re-iterating some thread long ago burried.

No, I don't think you are.

> > Again I'll ask the question I've already asked a number of times. How
> > would you cleanly support a construct like this:
> > opendir ("/dev/ide/cd");
> > loop;
>
> Although you bring this up in almost every posting in devfs, I'm not
> so sure if this is really an essential feature. It's nice, though.

The CDparanoia author wants devfs to go into the kernel so he can use
this.

But apart from that, it demonstrates a point that I've been labouring
to make. And I'll keep repeating it until the naysayers start thinking
about it and addressing it. The point is that this example
demonstrates the enormous flexibility of devfs combined with devfsd. A
flexibility that is denied if you don't have a virtual /dev.

A virtual /dev also could allow you to authorise module autoload
requests (because devfs know the initiating process). And many other
things. We haven't scratched the surface of what could be done with
devfsd hanging off a virtual /dev.

Regards,

Richard....

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.097 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site