Re: [PATCH 2/4] xen: Port linkage.h from kernel code

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.08.2022 12:16, Jane Malalane wrote:
> On 05/08/2022 10:24, Jan Beulich wrote:
>> On 04.08.2022 17:04, Jane Malalane wrote:
>>> Suggested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>>> Signed-off-by: Jane Malalane <jane.malalane@xxxxxxxxxx>
>>
>> In the title you say "port", but then you don't say what customization
>> you've done beyond the obvious adjustment of inclusion guard and
>> adjustment (actually removal) of #include-s. How much customization we
>> want to do is important here, after all. I notice you did, for example,
>> add new flavors of SYM_INNER_LABEL, but then you didn't add anything to
>> use .hidden (which I have queued as a new patch on top of a supposed v2
>> of "x86: annotate entry points with type and size"). At the same time
>> you've left in objtool related commentary, when we don't use that tool
>> (and no-one knows if we ever will).
>>
>> I'm further not sure I agree with the naming of some of your additions,
>> as they appear to not really fit with the naming model used elsewhere.
>> Your additions also look to not always match style used elsewhere in
>> this file.
>>
>> You further want to mention what Linux version this was derived from,
>> to make it easier to determine what incremental changes to port over
>> subsequently.
>>
>> Overall I'm not convinced this is a model we want to go with, first
>> and foremost because the commonly used macro names are too long for
>> my taste. What's wrong with ENTRY() and ENDPROC() / ENDDATA()?
> Hi Jan,
> 
> Since I have no particular opinion on this I went through the discussion 
> that took place before those macros were introduced in Linux. One of the 
> points made was that PROC was an ambiguous term to use, since C 
> functions are not actually procedures, at least not all.

Just one remark here: We're talking about assembly code here, so what's
a procedure or function isn't well defined anyway. I wouldn't, btw, mind
ENDFUNC() if that's deemed better than ENDPROC().

Jan

> The other was 
> that using START/END markers make it easier for a developer to remember 
> to add the END marker, and eventhough you suggest using ENTRY and not 
> just PROC as the start marker, START might still be clearer.
> 
> I welcome other input.
> 
> Thank you for your review,
> 
> Jane.