On Wed, 23 Jan 2019 at 10:55, Laszlo Er > > That's going to be a hard thing to keep from happening over time, as > > this is valid C :(sek <ler...@redhat.com> wrote: > > Hi All, > > On 01/23/19 04:43, Ni, Ray wrote: > >> -----Original Message----- > >> From: David Woodhouse <dw...@infradead.org> > >> Sent: Wednesday, January 23, 2019 12:23 AM > >> To: Ni, Ray <ray...@intel.com>; Gerd Hoffmann <kra...@redhat.com>; > >> Laszlo Ersek <ler...@redhat.com>; Richardson, Brian > >> <brian.richard...@intel.com> > >> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel@lists.01.org; > >> Kevin O'Connor <ke...@koconnor.net>; Anthony Perard > >> <anthony.per...@citrix.com> > >> Subject: Re: Drop CSM support in OvmfPkg? > >> > >> On Tue, 2019-01-22 at 16:13 +0000, Ni, Ray wrote: > >>> David, > >>> I'd like to re-start the discussion. > >>> Could you please kindly explain the background/reason of adding CSM > >>> support in OVMF? > >>> Maybe knowing the reason can help to make further decisions of > >>> whether to > >>> A. keep it outside OvmfPkg > >>> B. keep it inside OvmfPkg > >>> C. maybe have a chance to just remove the CSM support after > >>> revisiting > >> > >> > >> The idea was to make it simple to have a single firmware image for > >> virtual machines which would support both UEFI and Legacy boot for > >> guests simultaneously. > >> > >> In libvirt there has been an alternative approach, where the BIOS image > >> is switched between OVMF and SeaBIOS according to the configuration of > >> the guest VM. > >> > >> That's fine for libvirt, but in situations where VM hosting is provided > >> as a service, it becomes quite painful to manage the 'UEFI' vs. > >> 'Legacy' flags on guest images and then switch firmware images > >> accordingly. A one-size-fits-all BIOS using OVMF+CSM is very much > >> preferable. > > > > David, > > Thanks for sharing. I now understand that you do have a need of > > CSM + UEFI OVMF image. > > A very straightforward idea is to move all COM components you needed > > into OvmfPkg. But Laszlo as the OvmfPkg owner may disagree with this. > > So maybe you could set up another (github) repo and clone all the CSM > > components > > there. > > EDKII build tool supports to build firmware from multiple repos. > > That's how we can have edk2-platforms and to-be-created edk2-app. > > In practical, you could create a new csm repo. > > Laszlo/Gerd who don't care about CSM can just build OVMF image from edk2 > > repo. > > You can build the OVMF image from edk2 and csm repo. > > > > We can have a call if you are ok. I can explain how that can work in > > details. > > I'm fine if we move the generic CSM components into OvmfPkg, however I'm > going to ask David to assume reviewer responsibilities for them. > > Given the current format of "Maintainers.txt", we couldn't spell out the > exact pathnames of the CSM components, so we'd add a line like > > R: David Woodhouse <dw...@infradead.org> > > under OvmfPkg. There is "prior art" for this pattern, see: > > R: Anthony Perard <anthony.per...@citrix.com> > R: Julien Grall <julien.gr...@linaro.org> > > Because Anthony and Julien are the authority on Xen-related code under > OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers > to OvmfPkg", 2017-09-26.) > > > If we keep CSM support in OvmfPkg in any form at all, then I would > prefer holding all the related stuff in the core edk2 repository (with > the above Reviewership), over requiring people to deal with multiple > repositories. I agree (from experience) that PACKAGES_PATH / multiple > workspaces work fine, but in this case I think keeping one shared > history is an advantage. >
I don't have an opinion on whether we should keep CSM or not in OvmfPkg. But if we do, I agree we should just move all the pieces we rely on and that are getting dropped into OvmfPkg/ proper, rather than keeping them on the side somewhere. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
