From owner-freebsd-hackers@FreeBSD.ORG Tue May 20 13:40:34 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 08D8E37B401 for ; Tue, 20 May 2003 13:40:34 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F73B43F3F for ; Tue, 20 May 2003 13:40:33 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h4KKaKZ26172; Tue, 20 May 2003 13:36:20 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id NAA27444; Tue, 20 May 2003 13:40:15 -0700 (PDT) Message-ID: <3ECA91FD.1090509@btc.adaptec.com> Date: Tue, 20 May 2003 14:37:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <20030518005055.GG12759@sunbay.com> <200305192355.h4JNtx4e076037@khavrinen.lcs.mit.edu> <3EC986C6.5050800@btc.adaptec.com> <200305201733.43619.doconnor@gsoft.com.au> In-Reply-To: <200305201733.43619.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Garrett Wollman cc: freebsd-hackers@freebsd.org 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 20:40:34 -0000 Daniel O'Connor wrote: > [moved to -hackers] > > On Tue, 20 May 2003 11:07, Scott Long wrote: > >>The third step is to make the installer actually install the >>user-supplied drivers. Right now sysinstall has an option for loading >>KLD's from floppy, but that is all that it does. It doesn't help much >>when the driver you are loading is the storage driver for your >>installtion, and once you reboot the driver is not loaded automatically. > > > You'd need some way of knowing whether it's worth trying to load the module - > IMHO that is the difficult bit - it requires the most change to existing code > and is more likely to break things. > > >>I've wanted to work on this for quite a while, but I'm not sure I want >>to further the viability of sysinstall. However, others with less of a >>dislike of sysinstall are welcome to take this proposal and run with it. > > > If you tell me how to work out whether it's worth loading a given module from > a floppy I will quite happily write the code to implement it. > > Currently there is no special section which tells you whether you should try > and load something because a known PCI ID is present (for example - and yes I > know some modules use other criteria, but IMHO checking PCI ID's is a good > start) > > You could just trying loading every module on a disk but that is slow and you > can't really tell if the loaded module actually did anything useful without > kludgery. > > IMHO the module itself should hold descriptions and lists of ID's, but if they > have to be in a separate file then so be it. > > 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. > Having dealt with it in FreeBSD, SuSE, and RedHat, I see four possibilities. 1. The RedHat way: driver floppies carry a pci-id table file of id's that the driver supports. RedHat of course is a bit silly about this since their table only covers the Device and Vendor ID's and leaves out the sub-* Id's. It also doesn't have any wildcard matching capabilities. Also, it requires a separate effort to keep this table in sync with the driver. Certain scripting magic might be employed to help with this. 2. The SuSE way: driver disks contain only modules, and are loaded in a brute-force manner. I'm not really sure if they know that a driver succeeded/failed to load, and I think they just blindly install whatever drivers the user supplied. 3. Update the driver API to include requirements to give a PCI ID table in a certain format, and then update the module building framework to take this table and turn it into an elf section or something similar. 4. Update the kldload semantics so that the kldload syscall returns an indication of the driver's attach success/failure. This will allow the brute-force method to intelligently work. Scott