lkml.org 
[lkml]   [1998]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectdevlinks: an alternative to devfs
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.

Implementation-wise, a devlink can be implemented as a symlink with
some magic bit set (obviously only the super-user can set that magic
bit).

When a driver initializes (either at resident boot time or at module
initialization time), it needs to create devlinks in /dev. devfs
has a similar requirement that /dev be mounted at some point.
I propose a new system call, devctl( AUTO_DEVLINKS_GO_HERE, "/dev" ).
'init' or an init-job would issue this system call early in the boot
process.

With devlinks, this doesn't have to be right away, because all of the
existing contents of /dev are available as soon as the kernel boots.
So /dev/null, /dev/console, and any other essential /dev entries should
continue to be distributed as part of the root file system. It's only
the auto-created devlinks that need to have /dev "marked" in order to
auto-create. This solves a problem that devfs has, which is that
devfs needs to be mounted very early in the boot process and probably
can't be an ordinary /etc/mtab entry.

I have another devctl call, devctl( SEND_ENOENT_TO_KERNELD, "/dev" ).
After this is executed, any time an "open" call fails in the directory
"/dev", it gets forwarded to kerneld so that kerneld can do module
auto-loading (and then the module auto-creates its devlinks).

devctl allows a lot of flexibility during development and keeps all the
policy out of the kernel.

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

Devlinks coexist with the current system of block and character special
files. Drivers can be upgraded one at a time to support devlinks.

Devlinks can appear in any file system type that supports them.
They require only a little bit more code than symlinks. A file system
that doesn't support symlinks isn't suitable for /dev, but that's already
the case right now.

Devlinks can be put anywhere the administrator wants, such as chroot
jails, or devlinks in /tmp during a system installation.

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).

What do you think?

Michael Chastain
<mailto:mec@shout.net>
"love without fear"

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:1.794 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site