Messages in this thread | | | Date | Wed, 7 Jan 1998 09:09:24 +1100 | From | Richard Gooch <> | Subject | Re: devlinks: an alternative to devfs |
| |
Michael Elizabeth Chastain writes: > Here is another idea: devlinks, an alternative to devfs > > A devlink is similar to a symlink, but with the name of a device > driver rather than the name of another file: > > /dev/cua1 *-> char/tty:1 > /dev/hda *-> block/ide:0 > > A devlink has an owner, group, and permission bits, which can be > set in the usual way. A devlink persists across crashes and shutdowns > with no special work. > > The system administrator can rename a devlink to whatever they want, > so FSSTAND remains a user-space convention and is not enforced by > the kernel. Administrators can also create devlinks wherever they > want, for example, inside a chroot'ed file system. [...] > devlinks could also specify parameters to their drivers. For instance, > all of the /dev/fd* files would become devlinks like this: > > /dev/fd0 -> block/fd:0 > /dev/fd0D360 -> block/fd:0,format=360 > /dev/fd0D720 -> block/fd:0,format=360
I see a problem with this: when you open /dev/block/fd:0,format=360 the kernel will have to parse "fd:0,format=360" in order to determine which set of f_ops callbacks are required for that device. And it looks like you would need to search all these entries too. This is different than implementing a devfs, since it won't use the dcache. I think this scheme will be rather slow.
> Devlinks can be put anywhere the administrator wants, such as chroot > jails, or devlinks in /tmp during a system installation.
You can mount devfs N times.
> Devlinks solve the limitation of 8-bit minor numbers almost forever > (there is some huge limit on the length of a filename but I doubt that > will ever be a problem).
Personally: "yuk" :-) Sorry.
Regards,
Richard....
| |