Re: [PATCH v2 7/8] lib: move bsearch code

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

Hi Jan,

> On 9 Dec 2020, at 14:54, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 09.12.2020 15:27, Bertrand Marquis wrote:
>>> On 9 Dec 2020, at 09:41, Julien Grall <julien@xxxxxxx> 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.marquis@xxxxxxx>

so that this is unblocked.
Regards
Bertrand

> 
> Jan