Messages in this thread | | | Date | Wed, 13 Oct 1999 18:15:47 +0200 | From | Andreas Bombe <> | Subject | Re: My $0.02 on devd and devfs |
| |
On Mon, Oct 11, 1999 at 04:02:28AM +0000, H. Peter Anvin wrote: > The right solution -- which the devfs people have correctly identified > -- is a user-space daemon. However, once you have the user-space > daemon, "devd", I believe you neither need nor want the virtual > filesystem, in the general case. However, I can understand that in > some configurations (like embedded systems) it may be desirable. > > This is what I would like to see: > > * A device daemon, devd, which can add devices on demand. I was > thinking of one which would receive data packets like the following: > > <stub_name, type, major, first_minor, count, naming_scheme> > > e.g. > > <"ttyS", char, 4, 64, 192, "serial">
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/
| |