On 06/25/15 04:10, Ni, Ruiyu wrote: > Jordan, > I prefer to share the code across multiple platforms as well, if > that's possible. > > In real world, DUET's PciHostBridgeDxe driver does something > additionally: it gathers all option roms from PCI devices and > transfers them to its own special PciBus driver to dispatch.
> I am not familiar to OVMF and CorebootPayloadPkg's PciHostBridgeDxe > drivers. What specific behaviors do they do? The specific behaviors of OVMF can be seen in this patch series precisely. Please read: - the v1 blurb: http://thread.gmane.org/gmane.comp.emulators.qemu/342206/focus=15328 - the v2 blurb: http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15643/focus=15646 - and the commit messages of all the patches in v2. I'm getting pretty tired of having to wait for weeks to get just the most basic feedback, "what are you trying to do", when that's obvious from the patch series itself. In any case, very roughly: - The first half of the series only reformats and cleans up PciHostBridgeDxe. This part could be applied to the driver under PcAtChipsetPkg immediately. If you could find the time to review those patches, of course. As I pointed out earlier, these patches (on the list) are immediately reviewable for PcAtChipsetPkg too. - Other patches eliminate some *speculative* generality from the driver. The driver appears as if it could support multiple root bridges, but (a) that code is never actually put to use, (b) the code is static, not dynamic, (c) there is code that would be actually buggy if used with multiple root bridges. - The OVMF specific code implements a brute-force scan for extra root buses, and then uses a QEMU-specific optimization for shortening that brute force scan. > Can we generalize all the special behaviors to a common driver? I do > NOT like to introduce a bunch of PCDs like PcdDuet, PcdOvmf and > PcdCoreboot. The PCD that Jordan suggested was only for the very last step; ie. shortening the brute force scan. The PCD would live in the PcAtChipsetPkg token space, and would be set by platform specific code; in OVMF's case, it would be set by separate QEMU-specific code. ... For what it's worth, based on qemu-devel discussions that occurred since I had posted the OVMF v1 patch series, it seems that even the brute force scan for the extra root buses is QEMU specific. So even that patch might not be suitable for PcAtChipsetPkg. Thanks Laszlo ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
