Date: Sat, 10 Jan 2004 00:00:09 -0700 From: Scott Long <scottl@freebsd.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: "Matthew D. Fuller" <fullermd@over-yonder.net> Subject: Re: Discussion on the future of floppies in 5.x and 6.x Message-ID: <3FFFA2F9.3040707@freebsd.org> In-Reply-To: <20040110065054.GS25474@server.vk2pj.dyndns.org> References: <200401091400.40550.doconnor@gsoft.com.au> <3FFE5211.5040606@freebsd.org> <xzp1xq91oei.fsf@dwp.des.no> <20040109.075929.90380697.imp@bsdimp.com> <xzpad4xxhcs.fsf@dwp.des.no> <20040109210153.GP25474@server.vk2pj.dyndns.org> <xzpoetckf1k.fsf@dwp.des.no> <3FFF1BEE.9090400@freebsd.org> <20040109222654.GS48603@over-yonder.net> <20040110065054.GS25474@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy wrote:
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3FFFA2F9.3040707>