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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 17.08.2022 10:56, Jane Malalane wrote:
> On 16/08/2022 14:06, Jan Beulich wrote:
>> 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().
> Do you then propose that we use ENTRY() and ENDFUNC() and that for inner 
> labels we keep them as is (so just "name:"), since using ENTRY() without 
> a closing END() for some "functions" and not for others could get a bit 
> confusing?

Almost - I don't see anything wrong with using ENTRY() without any END*()
for inner labels, if the implied alignment is wanted. If no alignment nor
type / size are wanted, we have GLOBAL(). And recall that I already did
post a patch adding various ENDPROC() (which could be converted to
ENDFUNC() if that name is indeed liked better, and which could easily
have ENDDATA() or some such added), see
https://lists.xen.org/archives/html/xen-devel/2022-04/msg00876.html .
With Andrew's odd reply I didn't see fit to post a v2 so far, where I'm
now having a further patch adding .hidden directives into GLOBAL() and
(indirectly) ENTRY(). Not the least because my reply (where I did already
indicate that Linux'es machinery looks a little too involved to me)
didn't have any further responses, which would at least have helped
clarify what - if anything - I had "rejected" long ago.

Jan