![]() | |||||||||||||
Messages in this thread |
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.... | ||||||||||||
| Last update: 2005-03-22 12:41 [W:0.324 / U:0.590 seconds] ©2003-2008 Jasper Spaans | |||||||||||||