On Thu, 2018-12-20 at 07:44 +0100, Gerd Hoffmann wrote: > On Mon, Dec 17, 2018 at 10:54:25AM +0100, Laszlo Ersek wrote: > > (Adding Kevin, Gerd, David) > > > > On 12/17/18 03:23, Ni, Ruiyu wrote: > > > Hi OvmfPkg maintainers and reviewers, > > > I am working on removing IntelFrameworkModulePkg and IntelFrameworkPkg. > > > The biggest dependency now I see is the CSM components that OVMF depends > > > on. > > > So I'd like to know your opinion about how to handle this. I see two > > > options here: > > > > > > 1. Drop CSM support in OvmfPkg. > > > 2. Create a OvmfPkg/Csm folder to duplicate all CSM components there. > > > > > > What's your opinion about this? > > > > (1) Personally I never use CSM builds of OVMF. The OVMF builds in RHEL > > and Fedora also don't enable the CSM (mainly because I had found > > debugging & supporting the CSM *extremely* difficult). For > > virtualization, we generally recommend "use SeaBIOS directly if you need > > a traditional BIOS guest". > > On a virtual machine it is very simple to switch the firmware (unlike on > physical machines), which I think is the main reason ovmf+csm never > really took off.
Hm, that's true for virtual machines where you own the host system too and switching BIOS is just a matter of configuration. If you're running VM hosting at scale, however, and the customers don't get that level of control, then offering a single BIOS image which does UEFI and CSM in a "one size fits all" does have some merit. > > (3) However, David and Kevin had put a *lot* of work into enabling > > SeaBIOS to function as a CSM in combination with OVMF. Today, the CSM > > target is a dedicated / separate "build mode" of SeaBIOS. > > IIRC there are still some corner cases which are not working and nobody > wants put any effort into fixing them. S3 suspend comes to mind. Don't think that should be hard to fix if anyone really cares... > I'm not even sure it still works. It builds, yes, my jenkins instance > does that. But there is no testing beyond that, and I doubt that > someone else does regular ovmf+csm regression testing. So the chances > that any runtime breakage goes unnoticed are pretty high ... > > > (4) I also think an open source CSM implementation should exist, just so > > people can study it and experiment with it. > > It'll not be deleted from git, so it'll be there even when removed from > master branch. > > > In short, I think the community would benefit if someone continued to > > maintain the CSM infrastructure in edk2, Ruiyu (and Jordan), what's actually happening here? You said you were deprecating IntelFrameworkPkg... in the internal Intel builds, what replaces the CSM part? We fought to get parts of CSM support published to TianoCore from the internal tree, and I'm concerned that this is a regression — we end up with CSM support only being internal again. Or is it being dropped from the Intel tree entirely? I am very much against *increasing* the number of features which are supported in private repositories and not the public one.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
