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(). 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.
