On 01/12/2025 2:24 pm, Jan Beulich wrote: > On 01.12.2025 15:19, Andrew Cooper wrote: >> On 01/12/2025 8:46 am, Jan Beulich wrote: >>> On 28.11.2025 19:47, Andrew Cooper wrote: >>>> --- a/xen/lib/Makefile >>>> +++ b/xen/lib/Makefile >>>> @@ -17,6 +17,7 @@ lib-y += memset.o >>>> lib-y += muldiv64.o >>>> lib-y += parse-size.o >>>> lib-y += rbtree.o >>>> +lib-$(CONFIG_X86) += sha1.o >>>> lib-$(CONFIG_X86) += sha2-256.o >>>> lib-y += sort.o >>>> lib-y += strcasecmp.o >>> Why exactly are we confining the two SHA<n> to x86? They're both plain C >>> implementations, so ought to be fine to build everywhere. Being in $(lib-y) >>> they also wouldn't make it into the final binary until a reference would >>> appear. >> For the SHA2 patch, an objection was made to compiling it on the other >> architectures. Personally I think they ought to be plain lib-y. > Everyone (not knowing where the objection came from) - can we please re- > consider this, ideally ... > >> I could always have patch 1 fix up to lib-y and have patch 2 match... > ... allowing this to be done?
FYI, we discussed this on the committers/maintainers call, and decided that lib/ does want to be generally enabled. As such, I'll do as suggested. Have patch 1 make sha2 non-x86-specific, and have patch 2 be general from its introduction. ~Andrew
