Hi Oliver, On Tue, 31 Mar 2026 at 08:20, Oliver Smith-Denny <[email protected]> wrote: > > 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?
We had a stewards meeting today and discussed this topic. For now, let's start with moving ArmLib across to MdePkg. Once that's done, discussing what BaseLib should and shouldn't do can start. I'll also kick off a thread where we can start working on a plan towards abolishing ArmPkg/ArmPlatformPkg completely. (We will probably need to add something akin to PcAtChipsetPkg though.) Best Regards, Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121876): https://edk2.groups.io/g/devel/message/121876 Mute This Topic: https://groups.io/mt/118541649/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
