On 13.03.2025 18:02, Andrew Cooper wrote:
> On 13/03/2025 1:55 pm, Jan Beulich wrote:
>> For one there's no need for each architecture to have the same logic.
>> Move to the root Makefile, also to calculate just once.
>>
>> And then re-arrange to permit FAST_SYMBOL_LOOKUP to be independent of
>> LIVEPATCH, which may be useful in (at least) debugging.
>>
>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>> ---
>> Likely syms-warn-dup-y wants to follow suit; it doesn't even have an Arm
>> counterpart right now.
> 
> Recently, I thought the same about --orphan-handling={warn,error} too. 
> We need to up it to error, and enforce it consistently.
> 
> There's actually a lot of $(TARGET)-syms which ought to be less
> copy&paste.

Indeed. Iirc like me I think you indicated you'd like to also break up
those multi-step rules, to properly work through dependencies instead.

>  I'll submit my cleanup so far, which doesn't interact here
> I don't think, but is also incomplete.
> 
>> --- a/xen/Makefile
>> +++ b/xen/Makefile
>> @@ -460,6 +460,10 @@ ALL_OBJS-$(CONFIG_CRYPTO) += crypto/buil
>>  
>>  ALL_LIBS-y                := lib/lib.a
>>  
>> +all-symbols-y :=
>> +all-symbols-$(CONFIG_LIVEPATCH) += --all-symbols
>> +all-symbols-$(CONFIG_FAST_SYMBOL_LOOKUP) += --sort-by-name
>> +
> 
> I presume this works, so it's after we've processed Kconfig, but is
> there really nowhere better for it to live?

What do you mean by "better"? If we're to (slowly) centralize the
linking, this is where all of that would move. xen/Makefile is processed
just once (twice if .config changed), and ...

> If we're moving others, this is going to turn into a lot, and it's
> specific to one final stage.

... applicable in exactly that one case. Or are you suggesting to
introduce a new helper makefile where just the linking settings and
(eventually) logic live? That would be a bigger piece of work, which I'm
afraid I'm not up to right now.

For now it seemed quite natural to place all-symbols next to ALL_OBJS
and ALL_LIBS.

Jan

Reply via email to