Jordan, Simply using PCD to split the code is very straightforward. Another approach is to introduce a new library class with carefully defined library APIs so that different platforms can use one common driver plus different instances of libraries. After all, abstracting is never a easy work. So let's firstly make OVMF work by duplicating a PciHostBridgeDxe. What do you think?
Laszlo, I don't want to block you. And I do not see a big conflict between you and Jordan. Thank you very much for your continuously code contribution. Thanks, Ray > -----Original Message----- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Friday, June 26, 2015 3:07 AM > To: Justen, Jordan L; Ni, Ruiyu > Cc: edk2-devel@lists.sourceforge.net; Kinney, Michael D > Subject: Re: [edk2] [PATCH v2 02/24] PcAtChipsetPkg: remove > PciHostBridgeDxe > > Jordan, Ray, > > On 06/25/15 19:14, Jordan Justen wrote: > > On 2015-06-24 19:10:01, 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? > >> > >> 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. > > > > I think the names would not need to include the platform names. > > > > For this case, it seems like 1 or 2 PCDs would be sufficient: > > * PcdScanForAdditionalPciRootBuses (boolean / feature PCD) > > * PcdAdditionalRootBusesMaxBusNumber > > > > We could also only have 1 PCD (PcdAdditionalRootBusesMaxBusNumber) > and > > set it to 0 to disable the feature. > > here's my respectful request for the two of you: > > Please work out an agreement between the two of you, by the end of next > week, Friday, July 3rd, 2015, End-of-Business, in Jordan's timezone. > > (Reminder: the first version of the series (with practically identical > PciHostBridgeDxe impact) has been posted on June 6th, 19 days ago.) > > I have already agreed to both of your designs, but I can't satisfy both > at once, because your requirements conflict with each other. > > I'm (obviously) willing to implement what Ray suggests. > > I'm also willing to implement Jordan's suggestion, but then I will need > some form of *commitment* from Ray in advance. Namely, I said earlier, > and I'm saying again, that the *overwhelming majority* of the series > applies immediately to the driver in PcAtChipsetPkg, therefore Ray can > review those patches right now, on a higher level, and express if he > agrees with those patches ending up under PcAtChipsetPkg. > > I will be on PTO next week. If you can reach an agreement until next > Friday, I will do my best after, to implement that shared design of yours. > > If the two of you can't reach an agreement until next Friday, I will > abandon this series publicly, and we will carry it downstream only. > > 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
