On Tue Jan 13, 2026 at 4:19 PM CET, Andrew Cooper wrote: > On 13/01/2026 3:00 pm, Alejandro Vallejo wrote: >> 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. > > I'm explicitly not gating it. *-allcode is non-blocking, but I want > earlycpio being scanned. > > Simply omitting the second hunk should do this, and not explode the AMD > target build. (Once this patch is reordered to the end of the series.) > >> >>>> 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. > > *.init.o does two things: > > 1) For things we can tag, check everything is tagged > 2) For things we can't tag with __section(), such as string literals, > move them into .init > > > Fixing lib init properly should just be a case of sprinkling lib-y > through those places you mention. If you want me to do the patch then > fine, but I want it fixed rather than keeping on going around in circles.
I can do it, but I'll make a new series to deal with that independently of this if that's alright. Feel free to leave this patch uncommitted until then. I care far more about the next patch going in. Cheers, Alejandro
