[lkml]   [2004]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectFuture devfs plans (sorry for previous incomplete message)
	[Sorry for the previous incomplete message on lkml.  It was
the first time I've seen xterm segfault in a long time.]

Please do not delete devfs, as it provides important
functionality unavailable elsewhere, and I have some plans to improve
its implementation further.

Part 1: Advantages of devfs

devfs allows for creation of devices when user level programs
need them rather than based on "hot plug" or modprobe-related events,
neither of which do not exist for many devices and do not necessarily
indicate need for the driver. This allow distributions to include a
support for many more devices, without wasting a lot of unswappable
memory, which adds up when there are a lot of potential devices and,
in some cases, can make Linux perform better on platforms with limited
RAM. I can think of four classes of such devices:

1. hardware that does not generate "hot plug" events, such as
a conventional floppy disk drive. This way, distributions
can have support for all of these devices turned on without
bloating the kernel.

2. software devices, such as /dev/loop. Again, this way
distributions can include support for any such devices that
may be developed without a substantial cost in unswappable RAM.

3. hardware that is incidentally plugged in, but which might not
be used in the current session from boot to shutdown. With the
increasing popularity of USB and firewire, a user might have a
"webcam", a still digital camera, a digital video converter, a
flash reader, a printer, a scanner and an external disk that
happen attached to the computer's USB network, with the user
having no intention of using any of them during the current
session from boot to shutdown. This way, the cost of leaving
some things plugged in for convenience is reduced.

4. user level disk partitioning, which I've used for years, shrinking
the kernel a bit, and possibly enabling one to avoid spinning
up disks that are not going to be used.

In addition, devfs's use of names rather than number for
device identification in the kernel has the potential in the future to
help avoid issues of device ID number collisions, the "Linux assigned
names and numbers authority", and so on. System administrators that
do not like using devfs names directly can use the mechanisms provided
by devfs user level software to map to device names that they do like.

In any software, there is always a limit point to the
"mechanism versus policy" slogan where the complexity costs of
providing more generality are believe to outweigh the benefits for the
near future, especially if further generality could be added later if
the need were to arrise. For example, most ethernet devices are named
"eth%d", although we could conceivably add a translation layer for
that in the future. I believe that at some point in the distant
future, as part of a rearrangement of the distinctions between block
devices, char devices and device mappers, the method for connecting
the string passed to devfs_register() and the file name that
ultimately appears in /dev might change, but removing devfs in the
meantime would do more to impede such an effort and also would be
throwing the baby out with the bath water due to other advantages of
devfs discussed above.

Part 2: Future plans for devfs

Some time ago, I posted patches to replace the stock devfs
implementation with a much smaller one based on a specialized fork of
ramfs, replacing the devfs daemon with a facility for having the
kernel exec a helper program on devfs events. The kernel code was
about a fourth the size of stock devfs, and the user level code was
also reduced by a similar factor. I use slightly updated version of
that system on several systems every day, under 2.6.7. I can post
updated patches for this, but I also plan to implement some change

I plan to split out the functionality for invoking a user
level helper program on attempts to find or create a file, which
should provide the following advantages:

1. non-devfs configurations will be able to have demand loading
of device drivers that devfs systems currently enjoy.

2. The kernel memory footprint costs of CONFIG_DEVFS will be
even smaller, although the size of CONFIG_DEVFS +
CONFIG_lookup_helper will probably be slightly more than
that of my current mini-devfs.

3. It may provide a daemonless alternative to autofs for some
simple but common uses.

4. It will probably at least take us a step toward kicking dnotify
out to a demand loaded module (hey, it's unswappable memory that
every system currently uses, every byte counts).

5. It will probably provide a more general mechanism for
implementing dnotify-like systems that people periodically post
to the linux-kernel mailing list.

I have not yet written this vaporware, partly because I'm still
pondering the question of whether the facility for exec'ing a user
level program should be done as a few new lines in ramfs, a fork of
ramfs, or an extentsion and restructuring of dnotify. It should not
be many lines of code. It's just that I want to get it right.

Doing this as a ramfs variant would seem to contain the
changes and assure the non-users of this facility that there would be
no cost to them. So why not do it as a ramfs variant? Alas, doing
the user level helper facility as a ramfs variant would require adding
a parameter to inode_operations.lookup() because we need to filter out
the lookup event that occurs when an inode is being created.
Otherwise, in certain cases, loading a module that registers multiple
devices can cause a deadlock when the module's initial registration of
the device causes the devfs helper to block on trying to load the same
module again. Also, I wonder if there might be some use for layering
this facility on top of other file systems, such as /proc or /sys or
arbitrary storage file systems, but I haven't yet been able to come up
with any example. So, I think that making some general interface that
both dnotify and this facility could be clients of will probably be
the best approach, but there are definitely pros and cons to this
choice, and keeping that code small is something that I want to be
careful about.

I can post a new mini-devfs patch if there is interest,
although it may be the weekend before I have time to do even that.

In the meantime, please do not delete devfs. Thanks in

__ ______________
Adam J. Richter \ / | g g d r a s i l

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:04    [W:0.057 / U:33.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site