Re: [PATCH v3 3/4] earlycpio: lib-ify earlycpio.c

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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 <alejandro.garciavallejo@xxxxxxx>
>>> ---
>>> 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