Hi Peter,
Point 1.
Devfs has been argued about before, and it always seems to end in stubborn
heads butting against other. So if there's going be another discussion about
devfs, let's try to argue more productively. :) (both sides).
Onto the meat:
I mean this in the least offensive way, please don't take it personally, but
your posts on devfs, and especially the above comment, show that you havn't
really looked at devfs, and you don't know how it works. Please take a
minute or ten, put aside any technical or personal biases you may have,
download devfs and have a fresh look at it. It is actually quite clean and
well thought out, IMO.
- devfs does not implement policy.
The actual device names are not decided by devfs, and neither are
permissions.
Device names are decided by the driver registering them. It's the SCSI disk
driver that decides whether it's devices should be /dev/sd/c0b0t1u0 or
/dev/adaptec2/id1lun1part3, and then registers it as such with devfs. It
just happens that Richard obviously had to modify the drivers himself for
devfs, and so he chose his own names. But the names will be whatever the
*driver* wants. If the scsi disk layer has a way of knowing that controller1
is AKA adaptec1 then it can register it as such. Nothing to do with devfs.
Permissions are handled by a user space daemon. Ie all policy decisions are
left to a userspace daemon. (see below). Kernel devfs is just a /thin/ layer
to allow drivers to register device names in a 'virtual' directory.
- dev_t size and devfs are orthoganal.
increasing dev_t and devfs are solutions to different problems. (i'm
reffering to your other post). I don't think you can claim the former
invalidates the latter. What devfs can do however, is make more efficient
use of a limited dev_t through dynamic allocation. Increasing dev_t size is
still not going to make hot-plug things like USB clean.
NB: devfs benefits from increased dev_t aswell.
- Devfs *does* handle persistence.
A userspace daemon can communicate with kernel devfs, and handle events and
policy. So permissions can be consistent, and lot's more, eg execution of
scripts/programmes for certain events. the userspace devfsd that Richard
wrote is already very flexible and powerful, and there's nothing to prevent
further flexibility. The persistence argument against devfs is FUD.
- It doesn't have to be mounted on /dev
if you really don't like a virtual /dev, then you can still use devfs. Just
mount it somewhere else, eg /devices, and use the daemon to handle events
and update the static /dev accordingly. IIRC, T. T'so actually suggested a
similar scheme as being prefferable to devfs in an earlier debate, but devfs
already does it!
- We're going to need some kind of dynamic device allocation.
With USB/firewire/etc becoming more and more widespread and future
technologies also nearly certain to be 'plug-and-play', we're going to need
some kind of dynamic device allocation. Either that or /dev will really
become annoying if we go for an enlarged dev_t and static device allocation.
Also if linux is to be used on the desktop by less Unix aware users, we will
need some form of devfs I think.
I hope the above is a fair summary of the pro-devfs argument - as i see it
from previous discussions and from using devfs. I hope this thread won't be
as long-running and oblique as previous threads. Ie what I'd like to see is
a similar summation of the anti-devfs argument, and rebuttal of specific
points above. Let's work out a solution - wouldn't it'd be nice to end this
debate once and for all! :)
regards,
Paul Jakma.
paul@clubi.ie
-
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/