From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: DEVFS_FS Date: Fri, 12 Nov 2004 05:55:44 +0000 Message-ID: <20041112055544.GA21286@mail.shareable.org> References: <200411111953.iABJrK204297@freya.yggdrasil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Adam J. Richter" , linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:36225 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S262455AbUKLFzt (ORCPT ); Fri, 12 Nov 2004 00:55:49 -0500 To: Bryan Henderson Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: > To me, the criticism of devfs missed its most important feature: It was > fundamentally designed to eradicate device numbers altogether. Device > numbers are an ancient technology. In today's world, a device's basic > name should be something like /dev/sound/mixer instead of a small number. I agree. Numberless devices are so useful that even some non-devfs systems have a few drivers which allocate a number and require userspace to do horrible things like parse /proc/devices to open the device. Versions of udev that use /lib/udev-state/devices.tar.bz2 to workaround the limitation described below completely break this numberless feature. > If you miss that, and think devfs is about making mnemonic aliases for > small numbers, then it's easy to see devfs as a poor approximation of > udev. In my experience, udev has not been as good as people say, because while devfs just works, the udev-based system I'm using right now requires all manner of manual modprobing before basic things like pppd, openvpn and mtools work. > >Only devfs (or the lookup trapping facility used in my remake > >of it) can configure new devices on demand based on accesses to files > >missing from /dev, which allows for faster boot time (no need > >to initialize device you won't use during this session), easier fixing > >of device driver bugs, and potentially less memory utilization > > Why is that? First, let me make sure I parsed the sentence right: You're > saying the only way to configure devices on demand such that you get all > those benefits is by using your lookup trapping facility in conjunction > with your version of devfs? Wrongly parsed. He's saying _either_ devfs _or_ looking trapping is sufficient. > Also, I'm not clear on what memory utilization or device initialization > delays we're talking about. Examples: If you compile all USB drivers into the kernel, or if you modprobe them during boot scripts, then boot time is extended by the time taken to initialise the host controllers and connected devices. If you compile in SCSI drivers, boot time is further extended by the time taken to probe and initialise your SCSI devices. The time for initialising devices which you don't want to use this session can be quite significant, if you find a few seconds to be significant. Same goes for unnecessary memory utilisation. Having drivers loaded for devices which you aren't using can be significant, if you find a few hundred kbytes significant. -- Jamie