Discussion on the future of floppies in 5.x and 6.x

[Scott Long]

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