On 22 February 2016 at 13:11, Laszlo Ersek <[email protected]> wrote: > On 02/22/16 12:45, Ard Biesheuvel wrote: >> On 22 February 2016 at 11:24, Laszlo Ersek <[email protected]> wrote: >>> On 02/22/16 04:35, Ni, Ruiyu wrote: >>>> Ard, >>>> So the final decision between you and Jiewen is a new PCD is still needed? >>>> If so, could you move the PCD to MdeModulePkg? because the MdeModulePkg/BDS >>>> actually may also need this change if it's used in ARM64 platform and >>>> MdeModulePkg >>>> shouldn't depend on a PCD defined in IntelFrameworkModulePkg. >>> >>> Good point; I forgot about the possibility that a similar allocation >>> could be made in MdeModulePkg's BDS driver. >>> >> >> OK, I will change this. >> >>> (Also, although it's not urgent, it would be nice if we could again >>> think about migrating OVMF to the newest BDS in MdeModulePkg. Then >>> hopefully we'll have learned enough to migrate ArmVirtPkg too.) >>> >> >> I understand very little about how all the components interact. I was >> also surprised we use BdsDxe in IntelFrameworkModulePkg, and not the >> generic one (which contains the exact same code for the perfdata >> allocation below 4 GB) > > Last year Ray split the BDS driver under IntelFrameworkModulePkg into > two separate drivers under MdeModulePkg, in order to better separate the > BDS arch protocol responsibilities from the UI tasks (as I understand > it). This incurred some interface changes (affecting the GenericBdsLib > and PlatformBdsLib classes both). > > Therefore, current PlatformBdsLib instances have to be ported to the new > library class(es), if a platform wants to migrate to the new drivers. > This is not trivial. > > Ray submitted such a port for OvmfPkg: > > http://thread.gmane.org/gmane.comp.bios.edk2.devel/759 > > It was a very promising (and highly appreciated) start, but it needed a > lot more work (see my review comments there). In particular there was > one part in the series that I found almost completely incomprehensible. > Also, I asked for some of the lower-level functionality to be exposed, > in the library class, to platform code. > > So the idea is that hopefully Ray will find an opportunity sometime :) > to submit a v2 of that patch series. And after we migrate OVMF, we > should be able to migrate ArmVirtPkg ourselves, from the lessons > learned, without burdening Ray. > > It's not very urgent, because IntelFrameworkModulePkg's BDS driver (and > libraries) won't break overnight. (In fact I think I've seen even a few > bugfixes going into this driver, since.) But IIRC Ray said he would not > implement new UEFI spec features for it, so eventually we should move > off of it. >
Thanks for refreshing my memory. I was vaguely aware of the above, but I was not aware it covered BdsDxe as well. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
