Hi Jan, > On 9 Dec 2020, at 14:54, Jan Beulich <jbeul...@suse.com> wrote: > > On 09.12.2020 15:27, Bertrand Marquis wrote: >>> On 9 Dec 2020, at 09:41, Julien Grall <jul...@xen.org> wrote: >>> On 07/12/2020 10:23, Jan Beulich wrote: >>>> On 24.11.2020 17:57, Julien Grall wrote: >>>>> On 24/11/2020 00:40, Andrew Cooper wrote: >>>>>> On a totally separate point, I wonder if we'd be better off compiling >>>>>> with -fgnu89-inline because I can't see any case we're we'd want the C99 >>>>>> inline semantics anywhere in Xen. >>>>> >>>>> This was one of my point above. It feels that if we want to use the >>>>> behavior in Xen, then it should be everywhere rather than just this >>>>> helper. >>>> I'll be committing the series up to patch 6 in a minute. It remains >>>> unclear to me whether your responses on this sub-thread are meant >>>> to be an objection, or just a comment. Andrew gave his R-b despite >>>> this separate consideration, and I now also have an ack from Wei >>>> for the entire series. Please clarify. >>> >>> It still feels strange to apply to one function and not the others... But I >>> don't have a strong objection against the idea of using C99 inlines in Xen. >>> >>> IOW, I will neither Ack nor NAck this patch. >> >> I think as Julien here: why doing this inline thing for this function and >> not the others >> provided by the library ? >> Could you explain the reasons for this or the use cases you expect ? >> >> I see 2 usage of bsearch in arm code and I do not get why you are doing this >> for >> bsearch and not for the other functions. > > May I ask whether you read Andrew's quite exhaustive reply to Julien > asking about this? Apart from this, it was Andrew who had asked to > inline bsearch(), and I followed that request. The initial version > of this series didn't have any inlining of these library functions > (which, after all, also isn't the goal of the series).
I just did (sorry missed that one in the history). But seeing where this is called and the look of the code with this change i do not really think that the complexity introduced by this will make a real win in terms of performance/code size but it does make this complex. So I would rather have the inline part out but the code is right: Reviewed-by: Bertrand Marquis <bertrand.marq...@arm.com> so that this is unblocked. Regards Bertrand > > Jan