Er, this may not be clear, but you can register just about any kind of
inode with devfs. So a regular file (like /proc/mtrr, or much of the
other stuff in /proc) can easily live in devfs.
In fact, the devfs patch adds /dev/cpu/mtrr.
I'm not campaigning for a wholesale move of stuff from /proc to /dev,
but the recent talk about a new bus/device infrastructure, which
talked about a whole pile of stuff in /proc, frightened me. It's just
going further down a bad path.
> > You mean /dev/ide/bus#/cd/device# as compared to /dev/ide/cd/location#
> > I assume?
>
> Perhaps even /dev/ide/bus0/master (but, as I said, that may be too
> much purism - even Solaris doesn't quite go that far)
But what advantages would be derived from this purism (in the default,
kernel-supplied virtual FS)? If there was some use to this structure,
why not have devfsd create it from the existing structure that the
devfs patch provides?
At least the devfs patch provides a structure that is useful to user
space, leaving more advanced things to be configured with devfsd.
Rather than a structure that isn't useful until you massage it with a
devfsd-lookalike.
Ted now seems to be advocating something like devfs but mounted on
/devices, and have a daemon like devfsd populate/depopulate /dev.
And I suspect he's advocating having /devices be non-useful (i.e. to
look quite different than a reasonable /dev), just for the sake of
denying people the ability to mount re-badged-devfs onto /dev.
Speaking as a user, I'd resent that. If the work has been put into a
virtual device filesystem, but intentionally crafted to prevent me
mounting it on /dev... [censored].
> > Yes, although I think it would be more logical to reverse that order.
>
> If you wish ... I've used the order in which you'd issue
> chowns/chmods.
It's not an issue that I've formed a view on yet. Anyway, it's
off-topic for this list: it's a user space issue :-)
> > Anyway, you're basically agreeing with me that Ted's mutterings about
> > "persistence hacks" are a straw man.
>
> Well, as far as I can tell, you happen to have some persistence
> hacks ;-)
Yes, in a script I provide. So again, it's a user space issue :-)
> What I'm suggesting is to get rid of them plus the underlying
> problem (i.e. direct chmod/chown in /dev).
I'm not sure you could ever ban chmod()/chown() from user space, as
devfsd relies on that. And last time I looked, the VFS doesn't provide
a mechanism for denying permission changes for root, anyway (other
than a read-only FS). Well, I suppose there may be inode attributes
that could be played with, but that then leaves the problem of
allowing devfsd to change them but not plain root.
> > But: disallow chown() by the user? Users can't do that anyway.
>
> I mean "user" as in "user-space", which includes root.
So how does devfsd change permissions? In a previous incarnation I
thought about providing a chmod()/chown() interface via an ioctl on
/dev/.devfsd, but recent changes make that hack unnecessary.
> > The point is that this example demonstrates the enormous flexibility of
> > devfs combined with devfsd.
>
> Sure, but I think most of the critics have a problem with the core
> functionality, not the potential for doing other neat things, so in
> a way, this isn't relevant. Once the core bits are in you can
> quietly exploit the rest ;-)
The core functionality is actually less than people imagine. Not that
I've seen much evidence of people bothering to look.
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/