Date: Thu, 23 Jan 1997 11:47:29 +1030 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: se@freebsd.org (Stefan Esser) Cc: msmith@atrad.adelaide.edu.au, se@freebsd.org, current@freebsd.org Subject: Re: PCI LKM support added to -current Message-ID: <199701230117.LAA17394@genesis.atrad.adelaide.edu.au> In-Reply-To: <Mutt.19970122183655.se@x14.mi.uni-koeln.de> from Stefan Esser at "Jan 22, 97 06:36:55 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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 [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701230117.LAA17394>