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