Perhaps (don't have /proc/mtrr on any of my systems, so I don't know it
that well). In general, I don't think it's a good idea to try to pull
many things over from /proc into /dev, because a) people (and their
programs) expect to find them in /proc, and b) many items in /proc are
more like a text file than a device file in actual usage and in usage
policy. The distinction isn't perfect right now, but shuffling things
around won't make it better.
> 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)
> At least in part, devfs reflects the structure of the device
> drivers. And that structure makes a lot of sense.
Yes.
> 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.
> 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 ;-)
What I'm suggesting is to get rid of them plus the underlying problem
(i.e. direct chmod/chown in /dev).
> But: disallow chown() by the user? Users can't do that anyway.
I mean "user" as in "user-space", which includes root.
> 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 ;-)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_R_131__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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/