From: Jan Beulich <jbeulich@suse.com>
To: Julien Grall <julien@xen.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
George Dunlap <george.dunlap@citrix.com>,
Ian Jackson <iwj@xenproject.org>,
Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 00/23] further population of xen/lib/
Date: Thu, 1 Apr 2021 17:25:50 +0200 [thread overview]
Message-ID: <0d763d3a-6fcd-dd5c-803d-a52876a54f6c@suse.com> (raw)
In-Reply-To: <3bdbd0ba-ce7d-3814-3280-c4f628b74d93@xen.org>
On 01.04.2021 16:55, Julien Grall wrote:
>
>
> On 01/04/2021 15:27, Jan Beulich wrote:
>> On 01.04.2021 16:04, Julien Grall wrote: >> So overall, the number of functions requiring overriding will likely be
>>> pretty limited and #ifdef would be IMHO tolerable.
>>>
>>> Although, I would be OK with creating a file per function that are
>>> already overrided. For all the others, I think this is just pointless.
>>
>> Well, I don't see a reason to special case individual functions.
>> Plus any reasonable static library should imo have one (global)
>> function per object file in the normal case; there may be very
>> few exceptions. Drawing an ad hoc boundary at what currently has
>> an override somewhere doesn't look very attractive to me. Plus
>> to be honest while I would find it unfair to ask to further
>> split things if I did just a partial conversion (i.e. invest yet
>> more time), I find it rather odd to be asked to undo some of the
>> splitting when I've already taken the extra time to make things
>> consistent.
>
> I am sure each of us spent time working on a solution that some
> reviewers were not necessary convinced of the usefulness and they had to
> undo the series...
>
> In this case, you sent a large series with close to 0 commit message + a
> small cover letter. So I think it is fair for a reviewer to be
> unconvinced and ask for more input.
>
> You provided that now, I think we want a short summary (or a link to the
> conversation) in each commit message.
>
> This will be helpful to understand why the move was made without having
> to spend ages finding the original discussion.
I'll add "Allow the function to be individually linkable, discardable,
and overridable." to all the str*() and mem*() patch descriptions. Is
that going to be good enough?
Jan
next prev parent reply other threads:[~2021-04-01 15:26 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 10:14 [PATCH 00/23] further population of xen/lib/ Jan Beulich
2021-04-01 10:19 ` [PATCH 01/23] lib: move muldiv64() Jan Beulich
2021-04-15 10:00 ` Ping (x86): " Jan Beulich
2021-04-15 12:46 ` Roger Pau Monné
2021-04-01 10:19 ` [PATCH 02/23] lib: move 64-bit div/mod compiler helpers Jan Beulich
2021-04-01 14:56 ` Julien Grall
2021-04-01 15:23 ` Jan Beulich
2021-04-06 19:34 ` Julien Grall
2021-04-07 8:33 ` Jan Beulich
2021-04-07 14:06 ` Julien Grall
2021-04-01 10:20 ` [PATCH 03/23] string: drop redundant declarations Jan Beulich
2021-04-01 14:59 ` Julien Grall
2021-04-01 10:20 ` [PATCH 04/23] lib: move memset() Jan Beulich
2021-04-01 10:21 ` [PATCH 05/23] lib: move memcpy() Jan Beulich
2021-04-01 10:21 ` [PATCH 06/23] lib: move memmove() Jan Beulich
2021-04-01 10:22 ` [PATCH 07/23] lib: move memcmp() Jan Beulich
2021-04-01 10:22 ` [PATCH 08/23] lib: move memchr() Jan Beulich
2021-04-01 10:23 ` [PATCH 09/23] lib: move memchr_inv() Jan Beulich
2021-04-01 10:23 ` [PATCH 10/23] lib: move strlen() Jan Beulich
2021-04-01 10:23 ` [PATCH 11/23] lib: move strnlen() Jan Beulich
2021-04-01 10:24 ` [PATCH 12/23] lib: move strcmp() Jan Beulich
2021-04-01 10:25 ` [PATCH 13/23] lib: move strncmp() Jan Beulich
2021-04-01 10:25 ` [PATCH 14/23] lib: move strlcpy() Jan Beulich
2021-04-01 10:25 ` [PATCH 15/23] lib: move strlcat() Jan Beulich
2021-04-01 10:25 ` [PATCH 16/23] lib: move strchr() Jan Beulich
2021-04-01 10:26 ` [PATCH 17/23] lib: move strrchr() Jan Beulich
2021-04-01 10:26 ` [PATCH 18/23] lib: move strstr() Jan Beulich
2021-04-01 10:26 ` [PATCH 19/23] lib: move strcasecmp() Jan Beulich
2021-04-01 10:27 ` [PATCH 20/23] lib: move/rename strnicmp() to strncasecmp() Jan Beulich
2021-04-01 10:27 ` [PATCH 21/23] lib: move strspn() Jan Beulich
2021-04-01 10:28 ` [PATCH 22/23] lib: move strpbrk() Jan Beulich
2021-04-01 10:28 ` [PATCH 23/23] lib: move strsep() Jan Beulich
2021-04-01 11:54 ` [PATCH 00/23] further population of xen/lib/ Julien Grall
2021-04-01 13:43 ` Jan Beulich
2021-04-01 14:04 ` Julien Grall
2021-04-01 14:27 ` Jan Beulich
2021-04-01 14:55 ` Julien Grall
2021-04-01 15:25 ` Jan Beulich [this message]
2021-04-01 15:32 ` 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=0d763d3a-6fcd-dd5c-803d-a52876a54f6c@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@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).