Messages in this thread | | | From | "Jakma, Paul" <> | Subject | devfs again, (was RE: USB device allocation) | Date | Wed, 6 Oct 1999 10:41:07 +0100 |
| |
> Well, for one thing you just made your USB modem useless for dialout, > since you can't set the proper permissions for whomever you want to be > able to access your device. And they need to *stick* -- that implies > persistent storage. I'm sure there are similar > considerations for many > other peripherals. > > > -=hpa
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/
| |