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:
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]]
-=-=-=-=-=-=-=-=-=-=-=-
