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.