lkml.org 
[lkml]   [1998]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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....
\
 
 \ /
  Last update: 2005-03-22 13:41    [from the cache]
©2003-2011 Jasper Spaans