From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: DEVFS_FS Date: Tue, 16 Nov 2004 19:26:47 +0000 Message-ID: <20041116192647.GA19365@mail.shareable.org> References: <200411160609.iAG69gb05935@adam.yggdrasil.com> <419A5029.5010103@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "Adam J. Richter" , hbryan@us.ibm.com, linux-fsdevel@vger.kernel.org Return-path: Received: from mail.shareable.org ([81.29.64.88]:50051 "EHLO mail.shareable.org") by vger.kernel.org with ESMTP id S262115AbUKPT0w (ORCPT ); Tue, 16 Nov 2004 14:26:52 -0500 To: Mike Waychison Content-Disposition: inline In-Reply-To: <419A5029.5010103@sun.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Mike Waychison wrote: > The udev model does this very > effectively: where there is hardware backing the device files, there is > no good reason to not load the drivers and have policy set once and for > all on udevstart. (a) boot time, (b) it's typically a few hundred k to be saved. > The only need for trapping that I can see is for modules that don't have > hardware backing them, such as tun and loop. There's quite a few devices like that. > In fact, the opposite is true: userspace should not care at all about > major/minor. Userspace should care about the semantics of the available > device nodes available in /dev. With hardware, I want to _see_ the > device nodes created when I _add_ hardware. udev handles this semantic > very well. Where it fails is solely in the added devfs semantic of > modprobing on lookups of non-existing device nodes. _This_ is the case > where some form of trapping would help very much. I agree, this is desirable behaviour. But it isn't perfect. Better than trapping would be if /dev/net/tun0 and so forth did actually exist in /dev, to indicate the availability of those devices, but the modules were still autoloaded on first access. It would also be nicer if the device nodes were created to indicate available/installed devices, without actually initialising the devices or loading the bulk of their driver until they're needed. In other words, if /dev were auto-generated based on all available hardware and all available non-hardware drivers for the current kernel, including modules not yet loaded. That would be better IMNSHO, to the extent that it's possible. Although it's necessary to load drivers for some devices (like ISA cards) to detect them, it isn't necessary to load PCI drivers to detect that they are present. A mapping directly from detected PCI ids to whatever udev needs could be extracted from the drivers at compile time. Such mappings nearly exist now, except that the mapping is from ids to drivers, instead of ids to dev info. -- Jamie