From: Jan Beulich <jbeulich@suse.com>
To: Bertrand Marquis <Bertrand.Marquis@arm.com>
Cc: George Dunlap <George.Dunlap@eu.citrix.com>,
Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
Stefano Stabellini <sstabellini@kernel.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Julien Grall <julien@xen.org>
Subject: Re: [PATCH v2 7/8] lib: move bsearch code
Date: Wed, 9 Dec 2020 15:54:39 +0100 [thread overview]
Message-ID: <80ee54b1-5fd1-2aa8-606f-279c4b81a7ad@suse.com> (raw)
In-Reply-To: <689373AE-AF16-429F-818C-0467485E5748@arm.com>
On 09.12.2020 15:27, Bertrand Marquis wrote:
>> On 9 Dec 2020, at 09:41, Julien Grall <julien@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).
Jan
next prev parent reply other threads:[~2020-12-09 14:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-23 10:15 [PATCH v2 0/8] xen: beginnings of moving library-like code into an archive Jan Beulich
2020-10-23 10:16 ` [PATCH v2 1/8] lib: split _ctype[] into its own object, under lib/ Jan Beulich
2020-11-18 17:00 ` Julien Grall
2020-10-23 10:17 ` [PATCH v2 2/8] lib: collect library files in an archive Jan Beulich
2020-11-18 17:06 ` Julien Grall
2020-11-19 10:15 ` Jan Beulich
2020-11-18 17:31 ` Julien Grall
2020-11-19 10:44 ` Jan Beulich
2020-10-23 10:17 ` [PATCH v2 3/8] lib: move list sorting code Jan Beulich
2020-11-18 17:38 ` Julien Grall
2020-11-19 10:10 ` Jan Beulich
2020-10-23 10:17 ` [PATCH v2 4/8] lib: move parse_size_and_unit() Jan Beulich
2020-11-18 17:39 ` Julien Grall
2020-11-18 17:57 ` Julien Grall
2020-11-24 0:58 ` Andrew Cooper
2020-11-24 9:30 ` Jan Beulich
2020-10-23 10:18 ` [PATCH v2 5/8] lib: move init_constructors() Jan Beulich
2020-11-18 17:42 ` Julien Grall
2020-10-23 10:18 ` [PATCH v2 6/8] lib: move rbtree code Jan Beulich
2020-11-18 17:46 ` Julien Grall
2020-11-19 10:23 ` Jan Beulich
2020-10-23 10:19 ` [PATCH v2 7/8] lib: move bsearch code Jan Beulich
2020-11-18 18:09 ` Julien Grall
2020-11-19 10:27 ` Jan Beulich
2020-11-23 22:49 ` Julien Grall
2020-11-24 0:40 ` Andrew Cooper
2020-11-24 9:39 ` Jan Beulich
2020-11-24 16:57 ` Julien Grall
2020-12-07 10:23 ` Jan Beulich
2020-12-09 9:41 ` Julien Grall
2020-12-09 14:27 ` Bertrand Marquis
2020-12-09 14:54 ` Jan Beulich [this message]
2020-12-09 15:06 ` Bertrand Marquis
2020-10-23 10:19 ` [PATCH v2 8/8] lib: move sort code Jan Beulich
2020-11-18 18:10 ` Julien Grall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=80ee54b1-5fd1-2aa8-606f-279c4b81a7ad@suse.com \
--to=jbeulich@suse.com \
--cc=Bertrand.Marquis@arm.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=iwj@xenproject.org \
--cc=julien@xen.org \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).