Re: [edk2-devel] Move ArmLib to BaseLib
On Thu, 9 Apr 2026, at 19:33, Oliver Smith-Denny wrote: > On 4/8/2026 4:54 PM, Leif Lindholm via groups.io wrote: >> 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.) > > Thanks Leif. > > I can put up a PR moving ArmLib to MdePkg. We can decide in that PR on > whether to wait to merge it after the next stable tag or not (breaking > change, but also a pretty minor one). > Yes, please. And good luck with the spell checker :-) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121880): https://edk2.groups.io/g/devel/message/121880 Mute This Topic: https://groups.io/mt/118541649/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Move ArmLib to BaseLib
On 4/8/2026 4:54 PM, Leif Lindholm via groups.io wrote: 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.) Thanks Leif. I can put up a PR moving ArmLib to MdePkg. We can decide in that PR on whether to wait to merge it after the next stable tag or not (breaking change, but also a pretty minor one). Thanks, Oliver -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121879): https://edk2.groups.io/g/devel/message/121879 Mute This Topic: https://groups.io/mt/118541649/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Move ArmLib to BaseLib
Hi Oliver, On Tue, 31 Mar 2026 at 08:20, Oliver Smith-Denny 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 > 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 > 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]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Move ArmLib to BaseLib
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 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 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 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]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Move ArmLib to BaseLib
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 >> 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'. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121860): https://edk2.groups.io/g/devel/message/121860 Mute This Topic: https://groups.io/mt/118541649/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Move ArmLib to BaseLib
On 3/27/2026 1:56 PM, Leif Lindholm wrote: On Fri, 27 Mar 2026 at 20:25, Oliver Smith-Denny via groups.io wrote: Hi AARCH64 maintainers, As I am reviewing https://github.com/tianocore/edk2/pull/12340 and considering some of the efforts we've had to remove code from ArmPkg and ArmPlatformPkg (https://github.com/tianocore/edk2/issues/10289), I'm wondering if ArmLib should be largely (or completely) merged into BaseLib. Obviously, in most efforts moving code out of ArmPkg, we run into the ArmLib dependency and either need to add ArmPkg as a dependency of whatever package or give up on moving the code. ArmLib, as far as I can tell, was originally designed to be BaseLib for AARCH64 (its inf is even called ArmBaseLib.inf). TBH, I think the name is more because of MODULE_TYPE= BASE Yeah, fair enough. I haven't looked at each interface there, but the majority are interacting with registers, which is what other architectures use BaseLib for. E.g. ArmWriteVbar() is in ArmLib, x86's AsmWriteIdtr() is in BaseLib. I believe most of the functions would fall into this category of matching other architectures existing definitions in BaseLib. The definitions there may belong better in MdePkg/Include/AArch64; I need to look a little closer at those, but the page table defs for instance are there for x86. ArmLib only has a dependency on DebugLib and a quick test removing that dependency shows it isn't actually using it, which makes sense for inclusion in BaseLib. This does make BaseLib larger, of course, but also removes a special interface for AARCH64 only that all other architectures use BaseLib for. Thoughts? I think here be dragons, but I fully agree with your ultimate goal. I have a feeling non-x86 architectures will have more knobs to deal with, resulting in the larger size as you identify. Ultimately I wonder if that means some/much of what is in ArmLib today would better belong somewhere in UefiCpuPkg than being included for ... effectively every single app or driver. This might mean for consistency certain functions currently in BaseLib for other architectures should also move. This is definitely true (more knobs). I'm open to exploring other other options as well, say a ArchitectureRegisterLib or something that has a different API set per architecture. It's a bit odd in that sense, but BaseLib currently leans into that, which is why it seems somewhat reasonable to follow what I believe all the other architectures are doing and use BaseLib. e.g. RISCV64 which has the same I'm RISC with a lot of registers paradigm that AARCH64 has, uses BaseLib: https://github.com/tianocore/edk2/blob/c4d29cb62187060493a1f595083ddfb6dd346f39/MdePkg/Include/Library/BaseLib.h#L197. But also, since we support LTO pretty much everywhere now, maybe much of the bloat just gets eliminated? I suspect this is true. I can certainly do a test and see. At this point I do suspect ArmLib or a library with a dependency on ArmLib is already included in the majority of AARCH64 specific drivers, though, so it may not be that big of a delta (I would need to get some data to back this up of course, maybe I'm totally wrong). 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. Thanks, Oliver -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121855): https://edk2.groups.io/g/devel/message/121855 Mute This Topic: https://groups.io/mt/118541649/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] Move ArmLib to BaseLib
On Fri, 27 Mar 2026 at 20:25, Oliver Smith-Denny via groups.io wrote: > > Hi AARCH64 maintainers, > > As I am reviewing https://github.com/tianocore/edk2/pull/12340 > and considering some of the efforts we've had to remove > code from ArmPkg and ArmPlatformPkg > (https://github.com/tianocore/edk2/issues/10289), I'm wondering > if ArmLib should be largely (or completely) merged into BaseLib. > > Obviously, in most efforts moving code out of ArmPkg, we run > into the ArmLib dependency and either need to add ArmPkg as > a dependency of whatever package or give up on moving the code. > > ArmLib, as far as I can tell, was originally designed to be > BaseLib for AARCH64 (its inf is even called ArmBaseLib.inf). TBH, I think the name is more because of MODULE_TYPE= BASE > I haven't looked at each interface there, but the majority are > interacting with registers, which is what other architectures > use BaseLib for. E.g. ArmWriteVbar() is in ArmLib, x86's > AsmWriteIdtr() is in BaseLib. I believe most of the functions > would fall into this category of matching other architectures > existing definitions in BaseLib. > > The definitions there may belong better in MdePkg/Include/AArch64; > I need to look a little closer at those, but the page table defs > for instance are there for x86. > > ArmLib only has a dependency on DebugLib and a quick test removing > that dependency shows it isn't actually using it, which makes sense > for inclusion in BaseLib. > > This does make BaseLib larger, of course, but also removes a special > interface for AARCH64 only that all other architectures use BaseLib > for. > > Thoughts? I think here be dragons, but I fully agree with your ultimate goal. I have a feeling non-x86 architectures will have more knobs to deal with, resulting in the larger size as you identify. Ultimately I wonder if that means some/much of what is in ArmLib today would better belong somewhere in UefiCpuPkg than being included for ... effectively every single app or driver. This might mean for consistency certain functions currently in BaseLib for other architectures should also move. But also, since we support LTO pretty much everywhere now, maybe much of the bloat just gets eliminated? > 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. Thanks! / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#121854): https://edk2.groups.io/g/devel/message/121854 Mute This Topic: https://groups.io/mt/118541649/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
