Re: pci_device_id definition cleanups

[Greg KH]

On Fri, Feb 15, 2008 at 07:55:07PM -0500, Jeff Garzik wrote:
> Greg KH wrote:
>> On Sat, Feb 16, 2008 at 12:21:40AM +0100, Jonas Bonn wrote:
>>> I've done some work on cleaning up the definitions of pci_device_id to
>>> make them "static const" (where possible) and to make sure they go into
>>> __devinitconst.  There are about 350 changes of the type shown in the
>>> diff at the end of this mail.
>>>
>>> ???All these changes are in my public GIT tree at:
>>>
>>> git://www.southpole.se/~jonas/git/linux.git
>>>
>>> (Based on 2.6.25-rc2)
>>>
>>> In addition to these pci_device_id changes, there are a few changesets
>>> that move "const" data from __devinitdata to __devinitconst.
>>>
>>> The tree above builds with both allmodconfig and allyesconfig.
>> Hm, does this save us any memory on any type of configuration?
>> What about drivers that end up writing to these structures (I know some
>> USB drivers do, not sure about PCI ones.)
>
> I don't recall ever seeing a PCI driver do that... and if it exists on the 
> PCI side, I would be motivated to create patches to "fix" such behavior :)
>
> That information is exported to utilities that expect that table to be 
> static.  Messing around with it is just hacky, and bound to produce 
> unwanted edge cases.

Well, the USB drivers used to add an additional NULL entry at the end of
the list, and then populate it based on module parameters.  That way the
userspace tools would always work just fine, and you could add
additional device ids at run-time.

Now we have a way to do this for all USB and PCI drivers through sysfs,
so it's not needed, but we have to keep the backwards compatiblity for a
while in a number of USB drivers.

Hopefully PCI drivers didn't do the same thing, but I haven't looked at
all of them to verify this or not :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/