From owner-freebsd-hackers Fri Aug 30 20:28:16 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA16760 for hackers-outgoing; Fri, 30 Aug 1996 20:28:16 -0700 (PDT) Received: from trapdoor.dstc.edu.au (root@trapdoor.dstc.edu.au [130.102.176.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA16749 for ; Fri, 30 Aug 1996 20:28:12 -0700 (PDT) Received: from azure.dstc.edu.au (azure.dstc.edu.au [130.102.176.27]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id NAA10669; Sat, 31 Aug 1996 13:28:10 +1000 Received: (from leonard@localhost) by azure.dstc.edu.au (8.6.10/8.6.12) id NAA18695; Sat, 31 Aug 1996 13:28:09 +1000 From: David Leonard Message-Id: <199608310328.NAA18695@azure.dstc.edu.au> Subject: Re: PCI lkms To: peter@palin.cc.monash.edu.au (Peter Hawkins) Date: Sat, 31 Aug 1996 13:28:09 +1000 (EST) Cc: hackers@freebsd.org In-Reply-To: <199608310116.LAA06450@palin.cc.monash.edu.au> from "Peter Hawkins" at Aug 31, 96 11:16:51 am Reply-To: leonard@dstc.edu.au X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I was trying to do precisely that yesterday and after crashing my ISP > server decided I need help. If you come up with anything please let me know. the thing is that its a kind of plug and play thing. when the OS boots, the controller says 'hey i know that pci device!' and attaches the driver for it. otherwise, it sort of just ignores it. extending this outside the boot sequence (into rc with lkms) i havent yet seen done. (has anyone?) so, for now, i've got a compiled in driver that is simply a lot of stubs, and the lkm driver's load routine (is going to) update those stubs and restore them on unload. unless of course i can see a better way(tm) - like dealing with un-driven pci devices in /etc/rc somehow... automagically... mmm something like this: * normal boot, any compiled in pci drivers get attached as per normal * rc runs * the kernel is consulted for a list of pci device type/ids that it didn't recognise (via kvm) * for each unknown device, (somehow) a module in /lkm is modloaded the hard bit is devising a way to see which lkm will match a pci device without having to modload it. this might be possible by: 1. modloading every pci_*.o and it will fail on its load if it dont probe 2. encoding a type/id pattern in the filename 3. having a separate associated program (shell script?) for each module that replicates its probe (case "$1" in ... ) 4. encoding a type/id pattern in its symbol table maybe #1 (modloading every pci device driver) is acceptable; it just has to fail the load routine - return ENODEV if it doesnt probe. i personally dont like this idea because you could have heaps of drivers and they'd always have to be modloaded on each boot. if you have no pci devices plugged in you dont really want the overhead of say 10 modloads failing... way #2 is `yucky' :) and gets even more yucky when you can support multiple different device ids. (eg. de0). way #3 seems okay.. but just means the module isn't completely integrated perhaps someone who is a ld wizard could raise issues on the #4 way? (the DATA_SET macros absolutely blow me away!) I envisage something like this: have a dbm file (/var/db/pci_lkm.db ?) that you check the mod dates against everything in /lkm against. anything new with a filename pci_*.o you extract from its symbol table (somehow) a list of pci register0 ids that it would probe prositive for and store the tuple(s) `id -> pci_name.o'. (u_int32_t, char[]) d -- David Leonard Developer, DSTC The University of Queensland david.leonard@dstc.edu.au http://www.dstc.edu.au/~leonard/ >> Distributed Solutions Event http://www.dstc.edu.au/events/dse96/ <<