From owner-freebsd-current Wed Jan 22 17:17:48 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA16703 for current-outgoing; Wed, 22 Jan 1997 17:17:48 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA16672; Wed, 22 Jan 1997 17:17:36 -0800 (PST) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.2/8.7.3) id LAA17394; Thu, 23 Jan 1997 11:47:30 +1030 (CST) From: Michael Smith Message-Id: <199701230117.LAA17394@genesis.atrad.adelaide.edu.au> Subject: Re: PCI LKM support added to -current In-Reply-To: from Stefan Esser at "Jan 22, 97 06:36:55 pm" To: se@freebsd.org (Stefan Esser) Date: Thu, 23 Jan 1997 11:47:29 +1030 (CST) Cc: msmith@atrad.adelaide.edu.au, se@freebsd.org, current@freebsd.org X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Stefan Esser stands accused of saying: > > > > Please don't do it like that; put a data structure in the LKM file that > > contains this data and then write a utility to take the list of PCI > > device ID's and return a list of LKMs required to cover them. (You > > could add this to the utility that extracts the list of unhandled > > ID's from the kernel; just give it a path to where the LKMs live.) > > Sorry, but I don't quite understand what you want (and I assume > the problem is on my side :) Ok; what I meant was that rather than having a configuration file in /etc that lists LKMs and the PCI devices they match, put this information in the LKM itself, and write a tool to extract it on the fly. This way we avoid having yet another file in /etc that has to be updated every time an LKM is installed. > > device ID's and return a list of LKMs required to cover them. (You > > I'd rather have the list in a simple text file, which is updated > whenever a driver is added (or a device with a new PCI ID is found > to be sufficiently compatible to be handled by an existing LKM). I don't like this from a maintenance point of view. I understand that adding a line to a text file is easier than rebuilding an LKM, but I can think of ways around that as well 8) (leave extra space in the LKM's list and patch it...). > The current concept requires a list of PCI IDs to be available > in /etc/pcidevices. As part of /etc/rc a list of PCI devices is > retrieved, and if no driver is attached, then /etc/pcidevices > might map the PCI ID to a LKM name, which will be loaded by > modload and attached as part of the LKM initialization. The > attach makes the PCI code rescan the bus, and now there should > be a driver for the device that was found un-attached before > (and possibly for multiple cards, which can be handled by the > same driver). > > What's wrong with this ? Nothing other than the text file. I'm just suggesting that all of the information that would be in the text file _by_default_ should be obtainable from the LKMs themselves. In the case where a new PCI device appears that's not claimed by the LKMs but is compatible with another, a text file would provide a convenient way of 'aliasing', (but bear in mind that you will have to tell the driver that it's being asked to attach to a device that it doesn't actually know about). However, requiring the text file for any loading is a recipie for nuisance - remember that /etc is not normally updated by any of the build processes, so lots of people would end up with stale PCI LKM databases. ie. you would have a structure in the LKM that might look like this : static struct pci_lkm_matches { {0x055a, 0xa550, "PCI LKM Magic "}, {0x1234, 0x4567, "Frobozz Ink. Blarf 100 "}, {0x1234, 0x4569, "Frobozz Ink. Blarf 120 "}, {0xdeab, 0xbead, "Zoink 200/3 "}, {0, 0, "patchpatchpatchpatchpatch"}, {0, 0, "patchpatchpatchpatchpatch"} {-1, -1, " "} } Now, you can search for this in the LKM file using any one of several mechanisms (I'd go for rummaging its symbol table rather than the above which lets me do a search on the raw object...), and thus tell what the LKM was known to support when it was built. You can also optionally stuff more new things that it understands into the above data structure as an alternative to aliasing. I hope I'm making sense; I realise that my english is pretty tortured as it is 8( > Regards, STefan -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[