Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 19 Oct 2001 16:05:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 19 Oct 2001 16:05:01 -0400 Received: from mailout06.sul.t-online.com ([194.25.134.19]:44710 "EHLO mailout06.sul.t-online.de") by vger.kernel.org with ESMTP id ; Fri, 19 Oct 2001 16:04:42 -0400 Content-Type: text/plain; charset=US-ASCII From: Tim Jansen To: Mike Fedyk Subject: Re: [RFC] New Driver Model for 2.5 Date: Fri, 19 Oct 2001 22:07:39 +0200 X-Mailer: KMail [version 1.3.1] In-Reply-To: <15uerh-0NbBEeC@fmrl04.sul.t-online.com> <20011019122101.G2467@mikef-linux.matchmail.com> In-Reply-To: <20011019122101.G2467@mikef-linux.matchmail.com> Cc: linux-kernel@vger.kernel.org, Patrick Mochel MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-ID: <15uft5-12MXk8C@fmrl04.sul.t-online.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Friday 19 October 2001 21:21, you wrote: > > For example for harddisks. You usually want them to be mounted in the > > same directory. > When is /etc/fstab going to support this? You can use the device ids to provide stable symlinks, then /etc/fstab shouldn't be a problem. Or you rewrite mount to support it. Or you do it in the kernel with a user-space helper: when a new device is connected its ID is sent to some user-space app, and the user-space app then assigns a minor number and devfs name to the node. IMHO using the path of a file in /dev to identify a device node does not work in a hotplugging environment. You need this to support existing apps, but the only way to be sure that you always get the same device is to use device IDs. You could encode that device id in the node's path or use the path as a moniker for the device id (the symlink solution does this), but you need to have more information about the device than it's minor number (the X in /dev/lpX). > >Or for ethernet adapters: > > because each is connected to a different network, so you need to assign > > different IP addresses to them. > I haven't seen anything assign ethX assign a certain order, except for > ordered module loading, and then if there are multiple devices with the > same driver, the order is chosen by bus scanning order, or module option. Ok, but I think no one doubts that it is a bad idea to assign ethX semi-randomly. Basically this is the same problem as with device files, only in a different namespace. > Does anyone know if devfs will, or has any plans to support any of the > above features? The device registry (www.tjansen.de/devreg) patches devfs to allow the things described above though. bye... - 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/