[...]
> - 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/