On 02/28/18 08:53, Guo Heyi wrote: > On Wed, Feb 28, 2018 at 03:25:03PM +0800, Ni, Ruiyu wrote:
>> Heyi, >> My understanding is this whole change is backward compatible. >> Which means an old version of PciHostBridgeLib + new PciHostBridgeLib.h + >> new PciHostBridgeDxe driver won't cause build failure. >> right? > > Not really; as Laszlo indicated in one mail, some implementations of > PciHostBridgeLib uses temporary PCI_ROOT_BRIDGE_APERTURE variables and only > initialize Base and Limit fields of the variables, like the code in > https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c#L315 > and > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c#L216 > and > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c#L189 Right -- while Ray is asking whether this change can cause a build failure (and no, it can't), it is true that some PciHostBridgeLib instances don't fully clear some structures that "PciHostBridgeLib.h" defines (only member-wise assignments exist). So client code has to be patched up for functionality, not for build errors. > I'm also preparing the patches for these PciHostBridgeLib instances in edk2 > tree, which are expected to be committed after PciHostBridgeLib.h change and > before PciHostBridge driver change. That's a great idea; it should help with bisectability. In fact, you could submit those patches first (even independently); I think they'd mostly just insert a few well-placed ZeroMem() calls. One could argue that they should have been added right from the start (we expected the "PciHostBridgeLib.h" structures to expand over time, just missed a few init spots for them). Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
