On Tue, 2012-05-22 at 09:13 +0200, Alexander Graf wrote: > On 22.05.2012, at 09:01, Alexey Kardashevskiy wrote: > > This is internal kitchen of PCIDevice which I do not want to touch > from anywhere but pci.c. And > > there is no "fixup_capability" or something. > > Hrm. Maybe we should have one? :) Or instead of populating the config > space with the exact data from the host device, > loop through the host device capabilities and populate them using this > function as we go. > That should maintain the offsets, but ensure that all internal flags > are set, no? That actually sounds reasonable, though it might be more efficient to have something like pci_parse_config() or similar called once with a pre-cooked config space. Internally inside pci.c it can do that same loop you mention. The advantage is that it can also do whatever else we might need in the future. If for some reason, something wants to cache a cap pointer it can be done there, whatever else that is normally initialized as fields to generate the config space can be initialized by reading the config space and then initializing the fields etc... from that one function. Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
