All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bertrand Marquis <Bertrand.Marquis@arm.com>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Julien Grall <julien@xen.org>, Andrew Cooper <amc96@srcf.net>,
	Lin Liu <lin.liu@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>, Wei Liu <wl@xen.org>
Subject: Re: [PATCH v3 4/6] xen: Switch to byteswap
Date: Wed, 11 May 2022 14:16:36 +0000	[thread overview]
Message-ID: <773ED71F-3A5A-4682-82EB-8AB881D3D7FE@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.22.394.2205102012210.43560@ubuntu-linux-20-04-desktop>

Hi,

> On 11 May 2022, at 04:12, Stefano Stabellini <sstabellini@kernel.org> wrote:
> 
> On Tue, 10 May 2022, Julien Grall wrote:
>>> It is not reasonable to say "this unrelated thing is broken, and you
>>> need to fix it first to get your series in".  Requests like that are,
>>> I'm sure, part of what Bertrand raised in the community call as
>>> unnecessary fiction getting work submitted.
>> 
>> To be honest, you put the contributor in this situation. I would have been
>> perfectly happy if we keep *cpup* around as there would be only a place to
>> fix.
>> 
>> With this approach, you are effectively going to increase the work later one
>> because now we would have to chase all the open-coded version of *cpup* and
>> check which one is not safe.
> 
> 
> Without disagreeing with Julien or Andrew, I am actually happy to see an
> effort to make the review process faster. We have lot of room for
> improvement and spotting opportunities to do so is the first step toward
> improving the process. I have actually been thinking about how to make
> things faster in cases like this and I have a suggesion below.

Definitely with you here, it is good to see that my message on review process
and effort is actually in people’s minds :-)

> 
> In this case all of the options are OK. Whether we fix the alignment
> problem as part of this patch or soon after it doesn't make much of a
> difference. It is more important that we don't get bogged down in a long
> discussion. Coding is faster and more fun.

I would just make a small exception here (which corresponds to something
Julien kind of suggested during the discussion): unless we introduce a
temporary bug between the patches.
But this could actually be solved here by making a patch upfront and merging
it before the one in discussion (which might require some rebasing).

> 
> It would take less time for Julien (or Andrew) to write the code than to
> explain to the contributor how to do it. English is a good language for
> an architectural discussion, but simply replying with the example code
> in C would be much faster in cases like this one.
> 
> So my suggestion is that it would be best if the reviewer (Julien in
> this case) replied directly with the code snipper he wants added. Just
> an example without looking too closely:
> 
> ---
> Please do this instead so that alignment also gets fixed:
> 
> return be16_to_cpu(*(const __packed uint16_t *)p);
> ---
> 
> 
> Alternatively, I also think that taking this patch as is without
> alignment fix (either using be16_to_cpu or be16_to_cpup) is fine. The
> alignment could be fixed afterwards. The key is that I think it should
> be one of the maintainers to write the follow-up fix. Both of you are
> very fast coders and would certainly finish the patch before finishing
> the explanation on what needs to be done, which then would need to be
> understood and implemented by the contributor (opportunity for
> misunderstandings), and verified again by the reviewer on v2. That would
> take an order of magnitude more of collective time and effort.

Agree with the exception I mentioned.

> 
> Of course this doesn't apply to all cases, but it should apply to quite
> a few.
> 
> In short, less English, more C  ;-)

Same goes for things like “please add a comment” or “please say
something in the commit message”, it would be most of the time easier
for everyone to do: Could you add the comment “xxx” on top of this or
the sentence “yyy” in your commit (or even better ask the contributor if
he is ok with it and do it on commit when it not modifying the code).

Cheers
Bertrand


  parent reply	other threads:[~2022-05-11 14:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 10:15 [PATCH v3 0/6] Implement byteswap and update references Lin Liu
2022-05-10 10:15 ` [PATCH v3 1/6] xen: implement byteswap Lin Liu
2022-05-10 10:50   ` Andrew Cooper
2022-05-10 11:10   ` Julien Grall
2022-05-10 12:10     ` Lin Liu (刘林)
2022-05-10 16:18       ` Julien Grall
2022-05-10 10:15 ` [PATCH v3 2/6] crypto/vmac: Simplify code with byteswap Lin Liu
2022-05-10 10:51   ` Andrew Cooper
2022-05-10 10:15 ` [PATCH v3 3/6] arm64/find_next_bit: Remove ext2_swab() Lin Liu
2022-05-10 10:52   ` Andrew Cooper
2022-05-10 11:05   ` Julien Grall
2022-05-10 10:15 ` [PATCH v3 4/6] xen: Switch to byteswap Lin Liu
2022-05-10 10:51   ` Julien Grall
2022-05-10 11:09     ` Andrew Cooper
2022-05-10 11:17       ` Julien Grall
2022-05-10 11:34         ` Andrew Cooper
2022-05-10 11:47           ` Julien Grall
2022-05-11  3:12             ` Stefano Stabellini
2022-05-11  8:21               ` Julien Grall
2022-05-11 14:16               ` Bertrand Marquis [this message]
2022-05-11  9:56             ` Andrew Cooper
2022-05-11 10:55               ` Julien Grall
2022-05-11  6:30     ` Lin Liu (刘林)
2022-05-11  8:34       ` Julien Grall
2022-05-11 12:11         ` George Dunlap
2022-05-11 12:39           ` Julien Grall
2022-05-11 14:21           ` Bertrand Marquis
2022-05-17 14:59             ` Jan Beulich
2022-05-10 14:32   ` Anthony PERARD
2022-05-10 10:15 ` [PATCH v3 5/6] byteorder: Remove byteorder Lin Liu
2022-05-10 11:09   ` Andrew Cooper
2022-05-10 10:15 ` [PATCH v3 6/6] tools: Remove unnecessary header Lin Liu
2022-05-17 15:01   ` Jan Beulich
2022-05-17 15:18     ` 回复: " Lin Liu (刘林)

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=773ED71F-3A5A-4682-82EB-8AB881D3D7FE@arm.com \
    --to=bertrand.marquis@arm.com \
    --cc=amc96@srcf.net \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=lin.liu@citrix.com \
    --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.