I agree with you on that in general, but I would propose a different
design. Go for real simplicity.
Base the kernel to devd interface completely on strings. The messages
have some basic rules about the start but the args are completely left
to the driver. Every message contains a descriptive driver identifying
string (avoids need for central name/number allocation instance).
Examples:
add char 142 42 scsi-generic card=0 channel=1 id=4 lun=0
add block 141 13 scsi-disk card=0 channel=1 id=4 lun=0 partition=0
add block 141 14 scsi-disk card=0 channel=1 id=4 lun=0 partition=1
add block 141 15 scsi-disk card=0 channel=1 id=4 lun=0 partition=2
This would be part of the possible setup when a SCSI drive is found.
The major/minor numbers could be anything up to completely dynamic, we
could even think about a flat device number space is this would be
in any way desirable (just guessing).
Now to a hotplugging example (can also be applied to removable
partitioned media), a node removed on FireWire with the remaining nodes
shuffling their IDs:
remove char 145 0 ieee1394-raw card=0 id=0 uid=12345678fedcba09
remove char 145 1 ieee1394-raw card=0 id=1 uid=fedcba0912345678
remove char 145 2 ieee1394-raw card=0 id=2 uid=8765432190abcdef
add char 145 0 ieee1394-raw card=0 id=0 uid=8765432190abcdef
add char 145 1 ieee1394-raw card=0 id=1 uid=12345678fedcba09
The header (remove/add, char/block, major, minor) could be of course
made smaller by using numbers instead of strings there. What follows
is the driver name, the rest is completely up to the driver (except
that it must be in id=value format). What devd does with this is
completely up to (the configuration of) devd.
In the IEEE 1394 example it could e.g. add/remove device nodes in a
ieee1394-raw subdirectory in /dev using the unique IDs as device names.
In the SCSI example it could add or update (record permissions, remove
device node, mknod with new major,minor and recorded permissions)
device nodes of the form c0etcetc. Or it could create a directory tree
instead.
It only needs a devd that supports to be configured flexible enough.
Drivers would need to register themselves with the kernel side of the
devd pipe for the following reason: As long as no devd is running, the
configuration information lines are simply thrown away, assuming that
drivers know their configuration anyway and can always recreate them.
As soon as a devd connects to the pipe, all registered drivers are
asked to send a snapshot of their current configuration through the
usual channels in the usual ("add") format. devd can then catch up
without doing anything special and without losing anything.
Advantages:
- Device naming is now completely in user space, devices only announce
what hardware is connected and on which major/minor these are.
- When new drivers are included or some drivers extend their
information, only the devd configuration needs to be updated. devd
can stay the same until the kernel interface changes (unlikely for
such a simple interface).
- Simplicity. Device drivers use a printk() like interface to send
information to user space and don't care about anything else.
- Can be completely optional if done right (if drivers continue to use
a bit of consistency when allocating the minor numbers like they do
now). Can be applied on only part of the devices if so desired by
the administrator.
- If you don't care to / can't work without devd, arbitrary limits are
no longer required for the number of devices.
- Persistance of course. devd modifies real device nodes on
filesystems residing on disk. Also eliminates need for symlinks.
- devd can be replaced by something specialized (e.g. for embedded
systems). Due to the simplicity of the interface a replacement
wouldn't be hard to get right.
Disadvantages:
- Lots of string parsing, but IMHO device configuration is not time
critical at all. And the required id=value format makes it
relatively easy to parse.
- A devd approach requires a devd program in user space.
- Requires a real fs to operate on (but could be a ram disk in embedded
systems).
- Anything else?
--
Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/
RSA 0x886663c9 30 EC 09 73 84 7B 55 83 C4 7A 91 D9 9D C5 4B B0
DSA 0x04880A44 72E5 7031 4414 2EB6 F6B4 4CBD 1181 7032 0488 0A44
-
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/