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. ~Andrew
