On 3/31/2026 6:33 AM, Ard Biesheuvel via groups.io wrote:
On Fri, 27 Mar 2026, at 22:06, Oliver Smith-Denny wrote:
On 3/27/2026 1:56 PM, Leif Lindholm wrote:
On Fri, 27 Mar 2026 at 20:25, Oliver Smith-Denny via groups.io
<[email protected]> wrote:
...
If we agree on this general path, I will take up the work to merge
ArmLib into BaseLib (where appropriate). I will need to evaluate
each function closer, but again, a quick review seems like most would
be appropriate in BaseLib.
I vote yes.
Great, I'll wait to get some additional input, but I'll start taking
a look at this.
I think we may be conflating two different things here.
I agree that ArmPkg should not exist. And I agree that high-level functionality
that is tied to things like page tables etc should be abstracted in a generic
and portable manner, using a common library abstraction.
But that doesn't mean ArmLib should be subsumed by BaseLib. Some drivers are
fundamentally ARM-only, and rely on ArmLib today. Moving those pieces into
BaseLib serves no purpose whatsoever, and only increases the maintenance burden
of the latter, give that it adds more disparate pieces of functionality to a
library that has no defined purpose to begin with, other than a dumping group
for 'stuff that you almost always need when writing EDK2 source code'.
Well, my argument is that removing ArmLib does serve a purpose: it is a
major step in removing ArmPkg. Most of the remaining components in
ArmPkg depend on ArmLib, so moving them out is challenging until
ArmLib is dealt with.
Every other architecture uses BaseLib for the things ArmLib does. That
doesn't mean BaseLib is designed well, by any means. But it does mean
that AARCH64 is unique here. I would like to agree on what the proper
place for this functionality should be, regardless of architecture. So
far, I believe we are all in agreement that this place is not
<Architecture>Pkg. I think it is fair to say that architecturally
defined CPU operations (register interactions, etc.) should live in
MdePkg or UefiCpuPkg.
So, if we meet other architectures today, it would be BaseLib. If we
say that is the wrong abstraction point, that's fine, I don't disagree
there are many other options. But if we are going to do something new
for AARCH64, I'd like it to be what we say all other architectures
should do and then make that happen as well. My overall goal, in
aligning with the goal of removing ArmPkg, is to make AARCH64 a first
class, integrated citizen of edk2. Right now it feels more bolted
onto the side (hence ArmPkg and all of its own library classes instead
of integrating with existing edk2 library classes).
As I noted in an earlier email in this thread, I think there are
other options besides BaseLib. They just require changing other
architectures, too, but that's doable. We can have a CpuRegisterLib
that, like BaseLib today, has a different API set per arch. I don't
love libraries that do, that, but possible. We can say
<Architecture>Lib is the right approach (but should live in MdePkg or
UefiCpuPkg) and so ArmLib lives, but now there is an X64Lib, RISCV64Lib,
etc. These have only defined API set and are the parts of BaseLib
defined for those architectures.
I added Mike Kinney here, do you have thoughts, Mike?
Thanks,
Oliver
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121861): https://edk2.groups.io/g/devel/message/121861
Mute This Topic: https://groups.io/mt/118541649/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
