From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [edk2-devel] [RFC 07/13] MdeModulePkg/DxeCore: Permit preliminary CPU arch fallback To: Ard Biesheuvel ,devel@edk2.groups.io From: =?UTF-8?B?TWFydmluIEjDpHVzZXI=?= X-Originating-Location: Berlin, Land Berlin, DE (104.28.114.20) X-Originating-Platform: Mac Safari 16.3 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Mon, 13 Feb 2023 13:32:28 -0800 References: <20230213151810.2301480-8-ardb@kernel.org> In-Reply-To: <20230213151810.2301480-8-ardb@kernel.org> Message-ID: <18425.1676323948912560575@groups.io> Content-Type: multipart/alternative; boundary="SjUUzBKUR9p04ZRZPUcX" --SjUUzBKUR9p04ZRZPUcX Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Without wanting to blow up your RFC with another one - I discussed this wit= h various people, including Bret when he was still at Project Mu, and there= was a consensus among them that integrating the whole CPU arch code right = into DxeCore would be a good idea. This would especially remove the hack th= at queues permission applications till CpuDxe loads for good, rather than r= equiring pro-active consumption of a library that proves this "fallback". F= or most of the architectural protocols, especially SecurityStubDxe, I never= got the gist why you would want them to be separate from DxeCore. Obviousl= y there should be a level of customizability for IBVs and OEMs, though that= can be done statically-linked as well. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3D3223 What's your take on this? Best regards, Marvin --SjUUzBKUR9p04ZRZPUcX Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Without wanting to blow up your RFC with another one - I discussed this wit= h various people, including Bret when he was still at Project Mu, and there= was a consensus among them that integrating the whole CPU arch code right = into DxeCore would be a good idea. This would especially remove the hack th= at queues permission applications till CpuDxe loads for good, rather than r= equiring pro-active consumption of a library that proves this "fallback". F= or most of the architectural protocols, especially SecurityStubDxe, I never= got the gist why you would want them to be separate from DxeCore. Obviousl= y there should be a level of customizability for IBVs and OEMs, though that= can be done statically-linked as well.

REF: https://bugzilla.tianoc= ore.org/show_bug.cgi?id=3D3223

What's your take on this?

Best regards,
Marvin --SjUUzBKUR9p04ZRZPUcX--