Date: Mon, 17 Feb 1997 16:24:51 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: se@freebsd.org (Stefan Esser) Cc: hackers@freebsd.org Subject: Re: PCI LKM: How to find object file from PCI ID ... Message-ID: <199702170554.QAA08423@genesis.atrad.adelaide.edu.au> In-Reply-To: <19970131213621.EQ13588@x14.mi.uni-koeln.de> from Stefan Esser at "Jan 31, 97 09:36:21 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan Esser stands accused of saying: > Hi all! G'day! > I've been thinking about the best way to have a user-land program > determine, whether any of the object files in the /lkm directory > might be appropriate for some PCI device, for which no driver > exists in the kernel. ... > Since USB uses very similar device IDs and will require loading and > unloading of LKMs whenever a device is connected or deconnected (USB > supports hot-pluggable devices !), I would like to find a solution > that applies to USB, too. It is for that reason, that I consider the > real and CPU times required to identify the LKM ... I don't think that this is a serious issue; device arrival/departure is likely to be a fairly rare event. A generalised module identification mechanism would be neat. At the moment, the pccard stuff works reasonably well; the user-space tool waits for an 'arrival' announcement of some sort, which it then interprets and performs the appropriate action(s). This mechanism could easily be extended to include other devices (when the user-space program starts, it's presented with 'arrival' messages for already-present PCI etc. devices). > My prefered solution would be 1), currently, since only a low number of > PCI drivers exist. The file of PCI IDs could be automatically maintained > by each drivers install target in the Makefile. This maps to the current technique used by the PCCARD people. It's reaching its limits wrt. maintainability. > 3+4+5) put all the information into the LKM binary, and need no further > steps to be performed, besides moving the LKM in an agreed-upon directory. > I do not like the overhead of looking into some 30 files, which easily > might become 3 times as many, if more drivers are made available as LKM. If the overhead is a real problem, have a tool similar to ldconfig that processes all the files once and creates an index. Come to think of it, you could almost use ldconfig as-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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702170554.QAA08423>