Date: Sat, 31 Aug 1996 13:28:09 +1000 (EST) From: David Leonard <leonard@dstc.edu.au> To: peter@palin.cc.monash.edu.au (Peter Hawkins) Cc: hackers@freebsd.org Subject: Re: PCI lkms Message-ID: <199608310328.NAA18695@azure.dstc.edu.au> In-Reply-To: <199608310116.LAA06450@palin.cc.monash.edu.au> from "Peter Hawkins" at Aug 31, 96 11:16:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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/ <<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608310328.NAA18695>