From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 09:23:46 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40D3637B401 for ; Tue, 20 May 2003 09:23:46 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58C7343F3F for ; Tue, 20 May 2003 09:23:43 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.8/8.12.3) with ESMTP id h4KGNgkA004545 for ; Tue, 20 May 2003 10:23:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 20 May 2003 10:20:06 -0600 (MDT) Message-Id: <20030520.102006.08403290.imp@bsdimp.com> To: freebsd-hackers@freebsd.org From: "M. Warner Losh" In-Reply-To: <200305201733.43619.doconnor@gsoft.com.au> References: <200305192355.h4JNtx4e076037@khavrinen.lcs.mit.edu> <3EC986C6.5050800@btc.adaptec.com> <200305201733.43619.doconnor@gsoft.com.au> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: src/release/alpha dokern.sh drivers.conf X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2003 16:23:46 -0000 In message: <200305201733.43619.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : Currently I don't see a way of extracting PCI IDs from module source in a : standard way which means the lists would have to be maintained manually and : that would _suck_. Perhaps some standard struct array could be used, and if : it isn't present then you can't do a guess about whether to load the module : or not, so you just prompt the user. One of things on my list is to make it possible to have more than just PCI id's extractable from drivers. It is needed for devd so it can load the right things when it encounters devices for which there are no drivers. If the loader wants to do it too, that would be fine, but the only thing that I can think of that doing it in the loader would buy you that doing it in devd wouldn't is the ability to kldload the driver(s) necessary for the root device and not have them hard coded in your /boot/loader.conf file. Warner