Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 4 Jan 2002 07:48:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 4 Jan 2002 07:47:56 -0500 Received: from [129.27.43.9] ([129.27.43.9]:44048 "EHLO xarch.tu-graz.ac.at") by vger.kernel.org with ESMTP id ; Fri, 4 Jan 2002 07:47:44 -0500 Date: Fri, 4 Jan 2002 13:47:42 +0100 (CET) From: Alex To: Dave Jones cc: linux-kernel@vger.kernel.org Subject: Re: ISA slot detection on PCI systems? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Jan 2002, Dave Jones wrote: > On Fri, 4 Jan 2002, Alex wrote: > > > > You're still going to need user interaction for a lot of these. > > That is why I recommended that the textfile is the output of an > > interactive hardware-detection tool. Yes, interactive. :-) > > vim /etc/modules.conf > is about as interactive as it gets. Modules.conf is not all there is. What if modules.conf resides on an scsi-harddisk with an scsi controller who is just making the problem of ancient hardware in the first case ? etc.etc. You are running around with the underlying assumption that you can - indeed - *acess* modules.conf via *already detected* hardware. This is not the same assumption my textfile example operates from. My textfile-for-kernel operates from the assumption that *almost nothing whatsoever* on hardware is "fixed compiled" in the kernel at the moment we're talking about it, and that the precompiled modules will probably be loaded from the distro cd etc.... Later, Alex - 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/