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.
The exclude-list.json file goes stale after the move, so remove the entry
for earlycpio.c now that it's not included in AMD's build.
Its breakages will be fixed in due time and not ignored.
Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> # lib-ify only
Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # exclude-list.json
---
docs/misra/exclude-list.json | 4 ----
xen/common/Makefile | 2 +-
xen/lib/Makefile | 1 +
xen/{common => lib}/earlycpio.c | 0
4 files changed, 2 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..273e24db4a 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"
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..3b0137902c 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.init.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
--
2.43.0On 21.01.2026 16:47, Alejandro Vallejo wrote:
> --- 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"
Judging from Andrew's
https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
this doesn't quite work. As I had expected, since the file is compiled
unconditionally now in its new location, some violations are now also
unconditionally reported. (Some, checked for at linking time only, may not
be reported anymore for the *-amd analysis jobs.)
Jan
On 22/01/2026 8:27 am, Jan Beulich wrote:
> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>> --- 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"
> Judging from Andrew's
> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
> this doesn't quite work. As I had expected, since the file is compiled
> unconditionally now in its new location, some violations are now also
> unconditionally reported. (Some, checked for at linking time only, may not
> be reported anymore for the *-amd analysis jobs.)
Yeah, in hindsight this seems obvious, given that we're compiling then
discarding.
There are two options:
1. Use an earlier form which adds the new location to the exclude list
(Still needs to be in this patch for bisectibility.)
2. Fix up the violations first (only 6 in total)
Two of the violations look easy to fix, two need the deviation for octal
numbers, but two essentially-char violations look to be hard. The logic
is doing ASCII manipulation in what I would consider to be the
appropriate/canonical way, but Eclair does not like the mixture of ints
and character literals.
I dislike option 1, but as (contrary to my expectations) this is
interfering with the *-amd build, I'll tolerate it.
~Andrew
On 2026-01-22 13:50, Andrew Cooper wrote:
> On 22/01/2026 8:27 am, Jan Beulich wrote:
>> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>>> --- 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"
>> Judging from Andrew's
>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
>> this doesn't quite work. As I had expected, since the file is compiled
>> unconditionally now in its new location, some violations are now also
>> unconditionally reported. (Some, checked for at linking time only, may
>> not
>> be reported anymore for the *-amd analysis jobs.)
>
> Yeah, in hindsight this seems obvious, given that we're compiling then
> discarding.
>
> There are two options:
>
> 1. Use an earlier form which adds the new location to the exclude list
> (Still needs to be in this patch for bisectibility.)
> 2. Fix up the violations first (only 6 in total)
>
> Two of the violations look easy to fix, two need the deviation for
> octal
> numbers, but two essentially-char violations look to be hard. The
> logic
> is doing ASCII manipulation in what I would consider to be the
> appropriate/canonical way, but Eclair does not like the mixture of ints
> and character literals.
>
> I dislike option 1, but as (contrary to my expectations) this is
> interfering with the *-amd build, I'll tolerate it.
>
I agree that Solution 1 is the easiest to implement. An alternative
could be to fix the regressions for R7.1 and R20.7 (they're trivial)
regardless and add casts to sidestep MISRA for R10.2.
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
On Thu Jan 22, 2026 at 3:18 PM CET, Nicola Vetrini wrote:
> On 2026-01-22 13:50, Andrew Cooper wrote:
>> On 22/01/2026 8:27 am, Jan Beulich wrote:
>>> On 21.01.2026 16:47, Alejandro Vallejo wrote:
>>>> --- 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"
>>> Judging from Andrew's
>>> https://gitlab.com/xen-project/hardware/xen-staging/-/pipelines/2277362625
>>> this doesn't quite work. As I had expected, since the file is compiled
>>> unconditionally now in its new location, some violations are now also
>>> unconditionally reported. (Some, checked for at linking time only, may
>>> not
>>> be reported anymore for the *-amd analysis jobs.)
>>
>> Yeah, in hindsight this seems obvious, given that we're compiling then
>> discarding.
>>
>> There are two options:
>>
>> 1. Use an earlier form which adds the new location to the exclude list
>> (Still needs to be in this patch for bisectibility.)
>> 2. Fix up the violations first (only 6 in total)
>>
>> Two of the violations look easy to fix, two need the deviation for
>> octal
>> numbers, but two essentially-char violations look to be hard. The
>> logic
>> is doing ASCII manipulation in what I would consider to be the
>> appropriate/canonical way, but Eclair does not like the mixture of ints
>> and character literals.
>>
>> I dislike option 1, but as (contrary to my expectations) this is
>> interfering with the *-amd build, I'll tolerate it.
>>
>
> I agree that Solution 1 is the easiest to implement. An alternative
> could be to fix the regressions for R7.1 and R20.7 (they're trivial)
> regardless and add casts to sidestep MISRA for R10.2.
Easy as it is, and while I'd prefer to fix earlycpio.c, I just don't have
time to do it now. The original incarnation of the patch I sent that moved the
exclusion would work here.
That patch, followed by the lib move (as it was back then) ought to work for the
time being. I'm not in a hurry though so I'm happy for the move to wait until
someone finds the time to fix the errors. Whatever you prefer.
Cheers,
Alejandro
On 21/01/2026 3:47 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. Given what's committed, this becomes "when CONFIG_MICROCODE_LOADING=n" now. > The exclude-list.json file goes stale after the move, so remove the entry > for earlycpio.c now that it's not included in AMD's build. > > Its breakages will be fixed in due time and not ignored. ---8<--- exclude-list.json becomes stale with the move, but earlycpio is now absent entirely in the *-amd target build, so the violations don't matter. Simply drop the exclusion, so the logic gets scanned as part of the *-allcode targets. ---8<--- > > Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com> > Acked-by: Andrew Cooper <andrew.cooper3@citrix.com> # lib-ify only > Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # exclude-list.json Consider my A-by extended to a full R-by, and this looks fine to go in now. ~Andrew
© 2016 - 2026 Red Hat, Inc.