On 12/8/23 15:34, Laszlo Ersek wrote: > (7) Tying back to my point (4) -- I understand this is a hack anyway, > but I'm still uncomfortable with platform BDS uninstalling a protocol > that is owned by / provided by the CPU driver. Feels like a significant > layering violation. > > Can we modify the CPU driver instead, to listen to a new event group, > upon which being signaled, the CPU driver would uninstall the protocol > (and close the listening event)? > > This PlatformBootManagerLib instance would act more or less the same > (I'd suggest signaling the event group from within AfterConsole, in case > the PCD default and/or the fw_cfg knob dictated that), but the protocol > uninstallation would occur in "ArmPkg/Drivers/CpuDxe". > > In more technical terms, the layering violation IMO is that we mess with > CpuDxe's "mCpuHandle" and "mMemoryAttribute" static variables from > within BDS. Adding the new event group requires more boiler-plate code > for sure, but there's a small code-size benefit as well: we'd not have > to look up either the handle (with LocateHandle) or the protocol > interface (with HandleProtocol), as CpuDxe inherently knows those > (mCpuHandle, mMemoryAttribute).
Or maybe avoid modifying PlatformBootManagerLib completely; instead, move the logic into CpuDxe, into a ready-to-boot event handler? At that time, variable services should be available to CpuDxe as well (for the BootOrder UEFI var check). Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#112234): https://edk2.groups.io/g/devel/message/112234 Mute This Topic: https://groups.io/mt/103031504/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
