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.coop...@citrix.com>
>>>> Signed-off-by: Jane Malalane <jane.malal...@citrix.com>
>>>
>>> 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?

Jane.

Reply via email to