On Fri, Jan 09, 2004 at 04:26:54PM -0600, Matthew D. Fuller wrote:
On Fri, Jan 09, 2004 at 02:23:58PM -0700 I heard the voice of Scott Long, and lo! it spake thus:
Dag-Erling Sm?rgrav wrote:
yes, we need something like
struct pci_device_info { uint32_t pciid; char brand[64]; char model[64]; } my_supported_devices[] = { { 0x12345678, "Acme", "Nutcracker 2000" } };
which is placed in a separate ELF section so we can extract it from the module.
except it needs to be flexible enough to support other buses than PCI (SBUS, USB...)
DES
Yeah, this is a good suggestion, the only problem being in making it flexible enough to not be a burden on the drivers. Many drivers
keep one or more flag elements in their tables to flag hardware than
needs special attention. I'm sure that there are also countless other
pieces of state that drivers would want to associate with a table like
this.
I was poking around a bit (in my completely kernel-fu-lacking way) at this last night. For one thing, we could avoid the struct definition, and instead just mandate a few fields in the structure with given names as above. Then, write a little helper .c file with a main() that goes through the array (with the name given as a preprocessor -D or something) and spits the info out into a text file. Compile it up and run it for each module as we compile it, and assemble the results in a big reference file. Then, a userland program (like sysinstall, in this case) can easily poke through that text file to find and describe the drivers for devices found.
This is more what I was thinking in terms of. As well as the PCI ID and brand/model, we probably would need: - a priority field, so a generic driver can grab a device if a more specific driver isn't found - the option to use card ID instead of chip ID - wild-carding (maybe a bitmask)
And this still isn't enough to identify things like the Realtek 8139C+ chips that would prefer re(4) instead of rl(4) (though rl(4) is good enough to install FreeBSD).
Peter
Right, since there are at least 5 identifying fields in the PCI config space that might need to be looked at.
Lets not repeat the mistakes of vendors like RedHat that require that a duplicate table be maintained (with only 2 of the five fields!). Whether our tables are generated through script magic or through a stuctured API doesn't matter so long at it adds minimal burden to the driver maintainership and is guaranteed to always be in sync.
Scott
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
