Re: USB device allocation

Nathan Hand (nathanh@chirp.com.au)
Wed, 6 Oct 1999 23:11:49 +1000


On Wed, Oct 06, 1999 at 07:13:53AM -0500, Peter Samuelson wrote:
>
> [Nathan Hand <nathanh@chirp.com.au>]
> > Agreed. Getting rid of devfs (the dynamic filesystem) makes devfs
> > (the concept of dynamic /dev) more acceptable to more punters, and
> > honestly doesn't lose all that much functionality.
>
> Que sera sera. I like devfs (the concept of dynamic /dev) but enough
> important people don't that this may be the best that can be hoped for.

A compromise is always better than a stalemate.

> > Modules contact devfsd when they need a node. The daemon
> > creates/deletes nodes as needed on a real filesystem using the policy
> > laid out via /etc/devfsd.conf.
>
> If the daemon is deleting nodes upon cleanup_module(), you lose
> persistence. If it isn't, you lose the advantage of an uncluttered
> /dev with only current devices in it.

I really didn't want to discuss implementation details, but you don't
need to make it like you've described here. You can certainly make it
so devfsd only deletes nodes that are "swappable", or so that it will
never delete nodes, or that it will only delete nodes you indicate.

Ignore implementation details. Once it's in userspace you can do damn
well near anything. Your imagination is the limiting factor.

> With a real on-disk /dev, manual meddling with /dev nodes cannot be
> proscribed from on high or even detected (without evil dcache hacks) so

So?

> devfsd won't know if the user has mucked with /dev directly (i.e. not

So?

> through /etc/devfsd.conf). If you rename /dev/usbmouse0 to /dev/mouse,
> then unplug your USB mouse, then plug it back in, how will you keep
> devfsd from creating another /dev/usbmouse0? Any solutions regarding

Why stop it?

> doing a `find' on /dev in search of the correct major/minor will run
> afoul of trying to make those dynamic to alleviate the dev number
> shortage.

What's the problem?

> Sure, tell the user he has to edit /etc/devfsd.conf rather than
> changing /dev directly -- and you have now violated the Principle of
> Least Surprise. The VFS layer doesn't complain if he plays with /dev
> directly, so why can't you do it? With devfs, you can arrange for the
> VFS layer to use a warning label of -ENOSYS or -EPERM if you so desire.

You could "cat /dev/null > /proc/kcore" and the machine crashes. It's
impossible to make things bulletproof against the root user. So don't
try and do the impossible. Don't treat the -root user- like the idiot
fool who needs their hand held.

> > - Devfs gets into the kernel, everyone else in the world is happy.
>
> As I said, if Brave New (Almost-)All-Userspace Devfsd is the only way
> to satisfy hpa, tytso and the other VIPs, oh well. AIX does it this
> way and I have to admit that it does work, as long as you like the
> names and permissions AIX supplies you with.

Aye, it works beautifully, it's a good compromise.

What matters though is if the anti-devfs people agree.

-- 
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871   Fax: +61 2 6230 1515   E-mail: nathanh@chirp.com.au

- 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/