All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.