Messages in this thread | | | Date | Mon, 26 Jul 2004 14:24:36 +0800 | From | Trent Lloyd <> | Subject | Re: Future devfs plans (sorry for previous incomplete message) |
| |
Wouldn't a possible solution to do this to develop an extension to tmpfs to catch files accessed that don't exist etc and use that in conjuction with udev?
> [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 > soon. > > 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 > advance. > > __ ______________ > Adam J. Richter \ / > adam@yggdrasil.com | 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
-- Trent Lloyd <lathiat@bur.st> Bur.st Networking Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |