Dynamic Devices

Chris Jones (chris@black-sun.co.uk)
Fri, 8 Oct 1999 10:32:54 +0100


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi

I think that pretty much everyone has to accept that the existing
method of having major,minor device files in /dev is going to have to
go dynamic at some point or other (especially with the advent of hot
plug busses that allow vast numbers of devices to be connected at
once).

I for one happen to find having a bunch of files in /dev that aren't
used to be a mess (yes, I could go and remove the ones I don't need,
but they shouldn't have been there in the first place). I would much
prefer it to be dynamic, but I don't care that much if it is a kernel
space or user space solution (although user space is probably better).

The big problem people seem to be bitching about (and some of you
really are being bitchy about this) is persistance of
ownership/permissions on these device entries over reboots.

Now, I assume that when you chmod or chown a file (or in this case, a
dynamic device entry), the underlying fs is told that it has to
perform this change. At this point, the code responsible for handling
the dynamic devices can store this information along with some
information to uniquely identify the device connected (maybe a
combination of it's location on a particular bus, or a unique serial
number - whatever, that is a detail for the implementors to
determine). Doesn't this now cover all the major problems with a
dynamic solution?

If you have a userspace daemon and it is smart enough, you would be
able to produce complex rules regarding these dynamic devices, for
example, if I want to have an ISP running off my box with 512 USB
modems, I create some kind of rule in the userspace daemon's
configuration that all USB modems will be owned by user x and given
specific permissions. If I later want to add more modems, I just plug
and bunch in and they automatically get the right
permissions/ownership set on them.
You could probably even get it smart enough to be tailored to suit the
users - e.g. some people like having /dev/ttyS0-255 whereas some
people might prefer /dev/scsi/0/1/scd to denote a SCSI cd on ID 1 of
bus 0. If you are implementing all this stuff based on a userspace
daemon, this can all be configured and so long as you point stuff
correctly at your chosen layout everything will be hunky dory.

The point I'm trying to make is that if properly implemented, a
dynamic device system should be transparent to the system and the
users, but gives them the option to configure it in many ways to suit
their preferences. Surely that is a win-win situation all round?

Arguing against a dynamic driver system because you don't like an
existing implementation of it seems, to me at least, to be a complete
waste of time. I've never used devfs, but I like the idea behind it.
I'm totally unbiased because I know nothing about the implementation
of devfs or traditional devices, but I see dynamic devices as a
convienient solution to a very sticky problem (I probably wouldn't be
very happy if I did a MAKEDEV usb to find 255 new entries in /dev when
I only use a couple of USB devices and even then only very
occasionally - this also applies to the distros who seem to assume
that we are too dumb to mknod our own devices so they create hundreds
of the damn things for us).

One thing I have noticed is that Linus, Alan and Richard Gooch (author
of devfs) have all been utterly silent on this matter. I wonder why.

- ---
_____ _ _ _____
| __ | |___ ___| |_ ___| __|_ _ ___ Chris "Ng" Jones
| __ -| | .'| _| '_|___|__ | | | | chris@black-sun.co.uk
|_____|_|__,|___|_,_| |_____|___|_|_| www.black-sun.co.uk
S o f t w a r e

"Linux is beating Windows" - David Cole, Microsoft Executive

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.5.3i for non-commercial use <http://www.pgpi.com>

iQA/AwUBN/26Q5hmBipjerS3EQIDHgCfaB0byYBeML82+dGrJKL8YZtvagMAmQHy
tY00MpaK5q3G4Q4X02in29ft
=yWX2
-----END PGP SIGNATURE-----

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