Messages in this thread | | | Subject | Re: devfs again, (was RE: USB device allocation) | Date | Wed, 06 Oct 1999 13:01:56 -0400 | From | Horst von Brand <> |
| |
"Jakma, Paul" <Paul.Jakma@compaq.com> said:
[...]
> - 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. [...]
Names _are_ policy. So now I have to hack the kernel to rename the mouse?
[...]
> 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.
There is an even thinner layer that does that, called mknod(8)+chmod(1)...
> - 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.
Neither is any "dynamic" name assignment, where names are compiled into the kernel (see above). As none of the alternatives (devfs and increased dev_t) really solves this problem, which clearly is the central point of the exercise anyway, we have to look for something else.
> 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 is a complex mechanism to buy exactly what we had before. Violates KISS.
> - 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!
This has security implications... if I can somehow mount devfs with _my_ machinery to handle permissions (needed for "random user plugs in USB floppy", perhaps), the system is screwed. Again, goes against KISS.
> - We're going to need some kind of dynamic device allocation.
Not proven, AFAIKS.
> 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.
What is needed is a way to address _data_, not _devices_. A user cares about the document she is writing, not about "USB SCSI controller 2, device 14, partition 6, inode 417". The Unix way of handling files solves this for _fixed_ devices. For _removable_ devices (or media), I know of no real solution. Throw in the possibility of getting at data over FTP, HTTP, NFS, and whatnot (ultimate removability ;-).
As I see it, the problem(s) to be solved are much, much wider than just device naming. -- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- 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/
| |