> - I see that you've done away with the old /proc/pci, but have saved
> all the PCI vendor/device ID's, and use them to build device names
> that are now used in the resource tables. Is this really a good
> idea? Besides the fact that the string lists haven't been kept up
> to date (the kernel list is less than half of Martin's user-space
> list), do we really want this in the kernel? I know you have them
> as initdata, but it is still kernel image bloat, and there's also
> the minor issue that any hot swap PCI device can't be named the same
> because the strings will be gone.
>
> I'd suggest just naming all PCI devices as "pci <bus>:<slot>.<fn>"
> (for consistency with Martin's lspci) and leaving it at that. We
> can have a user-space pretty resource printer that cross-references
> the /proc files to get nice device names. Otherwise, we'll always
> have the hassle of keeping the kernel names in sync with the
> userland names.
This is exactly what I've proposed, but Linus insisted on keeping
the name list, so I've to surrender. Anyway, I'll write a simple
script generating the kernel ID list from the pci.id file, so that
it will be up to date.
> - There are PCI devices with additional resources that aren't covered
> by the base address registers. They can be handled in the PCI fixup
> code, but I'm not sure about where to put their resource structures.
> The devices I know about like this don't use some/most of their base
> address registers, so we could just use those unused structures??
I think this should be handled by the drivers itself since such
additional resources always correspond to legacy I/O ports and the
driver usually needn't know about which PCI devices really responds
to these ports.
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Quote of the day: '"- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/