On Tue, Jan 26, 2016 at 03:19:45PM +0100, Laszlo Ersek wrote: > >> Is this wise? It looks like BDS history repeating itself :-/ > > > > Well, medium-term, I'd (optimally) like to see ArmVirtPkg split and go > > into OvmfPkg one end and ArmPkg the other. > > > > But when Laszlo started out with ArmVirtPkg (before it indeed _was_ > > ArmVirtPkg), he felt the need to make substantial changes to > > PlatformIntelBdsLib, and opted to do it separately. > > We should probably take some time to look into what different needs we > > may actually have on physical rather than virtual platforms, and how > > we can go back to sharing the majority of the code. > > ** The main goals with the divergence visible in console setup were: > > - cut any ties with the ARM BDS > > (because, ArmPlatformPkg/Library/PlatformIntelBdsLib, despite being > an instance of PlatformBdsLib, to be plugged into the Intel BDS > driver, still uses ARM BDS related PCDs)
Yes, I prefer not to think about that. But we should be nearing the point where we can start yanking that out completely. > - make console detection dynamic > > (think USB keyboards, and VGA cards at non-fixed PCI addresses) Yes, we'll need this in physical platforms also. > IIRC, I had also experienced issues with > "ArmPlatformPkg/Library/PlatformIntelBdsLib" whenever a virtual machine > would start up with a brand new (= empty) variable store. For a physical > host this practically never happens, for a virtual machine, it can > frequently happen (you lose the varstore file or decide to delete & > recreate it from scratch). I vaguely recall that in such cases the > serial console wouldn't work at the first startup. (By now I'm fuzzy on > this, sorry.) > > Another example for the obscure console problems can be seen in SVN > r16912 (that patch predates the rewrite). > > The mailing list thread can be found at > > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/12954 > > I do believe my "going separate ways" was justified. At that time > ArmPlatformPkg had no PCI support at all, but ArmVirtualizationPkg did. > Both the VGA and USB controllers (all types of them), emulated by QEMU, > were PCI-based. So dynamic console detection made no sense for FVP, > Foundation, let alone the physical ARM machines, that ArmPlatformPkg > targeted at the time. Like Ryan's, my comment wasn't one of criticism of what you did, just a regret that we'd had a fragmentation. And following your lead is probably the way to start resolving that. > ... The device path of the serial console would not become dynamic; it > remained build-time static. I modified how it was represented though. > First, the ARM-related textual PCDs with the device path(s) in them were > an ARM BDS vestige. (See the first goal above.) Second, they are brittle > to configure for the end user; do we really want to construct > VenMsg(guid)-like strings manually? Typos are the norm, not the > exception. Third, parsing them into binary form in the code is a chore. > Because, do you do if there is indeed a typo and parsing fails? > > I stand by my idea (of patch #3 in the above-linked series) to encode > the device path of the serial console with a fixed binary structure in > the code. > > Later we would customize this for TTYTERM with SVN r17898. That would > still not require the user to edit device paths, just to pass a build > option. > > Finally, the rewrite gave the virt PlatformBdsLib a much-needed > structural cleanup (in my opinion anyway). It is now as minimal as > possible, and every line in there comes with its own justification. > Which is not something I thought of the pre-rewrite code. You'll get no arguments from me :) > ** Further features that only make sense for virtual machines (not an > exhaustive list, just what I can think of now immediately): > > - direct kernel boot from QEMU's fw_cfg interface > (see TryRunningQemuKernel() / "QemuKernel.c" / SVN r16578) > > - controlling UEFI boot order from the QEMU command line > (see SVN r16576, and the patches leading up to it) > > ... In fact, these last two features were implemented in one series, > chronologically *first*, and ultimately they are *the* reason for > splitting away from ArmPlatformPkg: > > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/11743/focus=11746 Both important features, but I would like to investigate whether they couldn't co-exist in the same PlatformBdsLib with compile-time selection. > ** Note that Ard and myself have not neglected keeping ArmPlatformPkg's > and ArmVirtPkg's PlatformBdsLibs in sync, whenever it made sense. (For > one, the Xen build of ArmVirtPkg still uses ArmPlatformPkg's > PlatformBdsLib!) For example, compare: > > - SVN r17713 > ArmVirtPkg: signal EndOxDxe event in PlatformBsdInit > > - SVN r18394 > ArmPlatformPkg: signal EndOfDxe event in PlatformBsdInit > > see also the discussion: > http://thread.gmane.org/gmane.comp.bios.edk2.devel/1849/focus=1916 > > > ** As for splitting up ArmVirtPkg and distributing it between > ArmPlatformPkg and OvmfPkg -- I think ArmVirtPkg is already as minimal > as possible. It pulls in a large number of libraries and drivers from > both ArmPlatformPkg and OvmfPkg. Speaking of the QEMU build, it only has > three drivers of its own (HighMemDxe, PciHostBridgeDxe, VirtFdtDxe). It > does customize a larger number of library instances, but library > instances are meant just for that. > > I'm not opposing this on principle, mind you, but I've been pretty > pleased with the current structure, so I'll have to see concrete ideas > to set my mind to a different track. :) Sure. And I need to have some spare cycles before I get back to you with that. I just don't like having another top-level package for every new virtualised architecture, and having people using different names for running UEFI on qemu-aarch64 than for running UEFI on qemu-x86_64. Regards, Leif _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
