lkml.org 
[lkml]   [1999]   [Oct]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: devfs again, (was RE: USB device allocation)
Date
From
"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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.041 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site