Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 15 Jan 2002 17:57:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 15 Jan 2002 17:57:31 -0500 Received: from cpe-24-221-152-185.az.sprintbbd.net ([24.221.152.185]:56192 "EHLO opus.bloom.county") by vger.kernel.org with ESMTP id ; Tue, 15 Jan 2002 17:57:18 -0500 Date: Tue, 15 Jan 2002 15:56:52 -0700 From: Tom Rini To: Alex Bligh - linux-kernel Cc: Justin Carlson , esr@thyrsus.com, linux-kernel@vger.kernel.org Subject: Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution) Message-ID: <20020115225652.GB5220@cpe-24-221-152-185.az.sprintbbd.net> In-Reply-To: <20020115013025.GA3814@cpe-24-221-152-185.az.sprintbbd.net> <197055869.1011134770@[195.224.237.69]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <197055869.1011134770@[195.224.237.69]> User-Agent: Mutt/1.3.25i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 15, 2002 at 10:46:11PM -0000, Alex Bligh - linux-kernel wrote: > >>From the other side, how does having the ability to probe local hardware > >>hurt? It should be cleanly seperable from the classical build process > >>for the purists, and helpful to some (I think) significant portion of > >>the userbase, particularly those folks who like to test bleeding edge > >>stuff on a variety of hardware. I don't really understand the > >>resistance to the idea of someone going out and implementing this. > > > >Right, and this is 95% possible even. Doing PCI stuff is rather easy > >(since we've got it all mapped out even). The problem is the 100% > >point-click-run goal that Eric has. > > > >The original sticking point was doing ISA (and other buses that are > >_not_ autodetect friendly in a safe way). > > & this has a seemingly obvious solution, [snip] > those, which when loaded on a system not containing the relevant > card, can cause a hangup; thus deferring the autoprobing until > boot time. If everything worked before as a module, this works still. If not, you need to have a for loop or something that attempts to load every XXX subsystem driver. But the point I was getting at is the 100% solution isn't possible. Even if we narrow the scope of the problem to just x86 hardware, theres still things which can't be solved. Talking to random memory locations will bite you at somepoint on some hw. Old busses weren't designed with any sort of autoconfig in mind. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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/