On Tue Jan 13, 2026 at 3:24 PM CET, Andrew Cooper wrote:
> On 13/01/2026 12:21 pm, Alejandro Vallejo wrote:
>> It's only used for microcode loading on x86. By lib-ifying it we can make
>> it go away automatically when microcode loading becomes an optional
>> feature in follow-up patches.
>>
>> Signed-off-by: Alejandro Vallejo <[email protected]>
>> ---
>> v3:
>> * New patch. Subsumes earlier conditionalisation of earlycpio.c on
>> CONFIG_MICROCODE_LOADING.
>> ---
>> docs/misra/exclude-list.json | 8 ++++----
>> xen/common/Makefile | 2 +-
>> xen/lib/Makefile | 1 +
>> xen/{common => lib}/earlycpio.c | 0
>> 4 files changed, 6 insertions(+), 5 deletions(-)
>> rename xen/{common => lib}/earlycpio.c (100%)
>>
>> diff --git a/docs/misra/exclude-list.json b/docs/misra/exclude-list.json
>> index 388397dd3b..2b874dfd3b 100644
>> --- a/docs/misra/exclude-list.json
>> +++ b/docs/misra/exclude-list.json
>> @@ -121,10 +121,6 @@
>> "rel_path": "common/bunzip2.c",
>> "comment": "Imported from Linux, ignore for now"
>> },
>> - {
>> - "rel_path": "common/earlycpio.c",
>> - "comment": "Imported from Linux, ignore for now"
>> - },
>> {
>> "rel_path": "common/gzip/*",
>> "comment": "Imported from Linux, ignore for now"
>> @@ -225,6 +221,10 @@
>> "rel_path": "include/xen/decompress.h",
>> "comment": "Imported from Linux, ignore for now"
>> },
>> + {
>> + "rel_path": "lib/earlycpio.c",
>> + "comment": "Imported from Linux, ignore for now"
>> + },
>> {
>> "rel_path": "lib/find-next-bit.c",
>> "comment": "Imported from Linux, ignore for now"
>
> Honestly, I think this needs simply dropping. "ignore for now" isn't
> going to cut it with any competent evaluators.
That would depend on justifications and such. But regardless clearing the
exclusion list is a different matter aside from removing microcode loading.
>
> By libryfing it, it's no longer part of the AMD target build, but it
> does want covering by *-allcode.
>
> Given that you noticed it for v2, I presume there's something in the
> file that Eclair doesn't like?
I didn't run Eclair on it. It's ignored as part of common, and the build
fails in CI if the file in common is absent. That's how I noticed it.
I'd rather not gate this particular change on earlycpio playing ball with
Eclair.
>
>> diff --git a/xen/common/Makefile b/xen/common/Makefile
>> index 92c97d641e..4fc0c15088 100644
>> --- a/xen/common/Makefile
>> +++ b/xen/common/Makefile
>> @@ -65,7 +65,7 @@ obj-y += wait.o
>> obj-bin-y += warning.init.o
>> obj-y += xmalloc_tlsf.o
>>
>> -obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo
>> unlzo unlz4 unzstd earlycpio,$(n).init.o)
>> +obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma lzo
>> unlzo unlz4 unzstd,$(n).init.o)
>>
>> obj-$(CONFIG_COMPAT) += $(addprefix compat/,domain.o memory.o multicall.o
>> xlat.o)
>>
>> diff --git a/xen/lib/Makefile b/xen/lib/Makefile
>> index efca830d92..60cfda4dfc 100644
>> --- a/xen/lib/Makefile
>> +++ b/xen/lib/Makefile
>> @@ -3,6 +3,7 @@ obj-$(CONFIG_X86) += x86/
>> lib-y += bsearch.o
>> lib-y += ctors.o
>> lib-y += ctype.o
>> +lib-y += earlycpio.o
>> lib-y += find-next-bit.o
>> lib-y += generic-ffsl.o
>> lib-y += generic-flsl.o
>> diff --git a/xen/common/earlycpio.c b/xen/lib/earlycpio.c
>> similarity index 100%
>> rename from xen/common/earlycpio.c
>> rename to xen/lib/earlycpio.c
>
> What's wrong with .init here? There's only a single string which will
> end up unmerged so I'm not worried on this side of things, but we now
> have series doing safety things getting tangled with .init and I want to
> get it fixed.
.init.o doesn't work with lib-y; only obj-y, obj-bin-y and extra-y. See below:
$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): CFLAGS-y +=
-DINIT_SECTIONS_ONLY
[snip]
non-init-objects = $(filter-out %.init.o, $(obj-y) $(obj-bin-y) $(extra-y))
[snip]
$(filter %.init.o,$(obj-y) $(obj-bin-y) $(extra-y)): $(obj)/%.init.o:
$(obj)/%.o FORCE
$(call if_changed,obj_init_o)
That's just what I eyeballed. There might be more hidden elsewhere.
It might want fixing, specially if something like libfdt is to turn into
a library. But it's just not relevant for this particular change where the
single contained function is already __init.
Cheers,
Alejandro
