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