[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 4/6] xen: Switch to byteswap


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Wed, 11 May 2022 14:16:36 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Txrs/sgZUAQdW+NVVTKGqX4PfNujslWU935SxZMzkXk=; b=aenlN/3fbgzEMoFYCSUVgVlMbp+VfjVSkjskSgBUeoPAed3uMMAS0EcSX6MhOQxZPAYWamlRcmLRLEXj0FEcWCVM7mBXcLW9LGDpcTdFajrcOoUOQZW6uG+Mf1FMqfWtPJki92tLc1BeuGEGFvlB/D8zEuyFVaurhefgrhKSebDskaYEUyxxO2XmRIT6QJw+4rg8tpfhuHfGSG+oUE1qnPCdCB+GHh1DkcbCQt3YPBlAh76PxlHoBEDHnT9kfqfkR+zG+bfMR0D4kLFI5N+iradQAw+HCYnmpMaA0GqolOaZjcZ2C0gryk2Mq873KbpTWBJE5DLzM7OjMu98CMoDwQ==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Txrs/sgZUAQdW+NVVTKGqX4PfNujslWU935SxZMzkXk=; b=Q7yFRuMP+1+VDUUK4ktILVi3+joGiWUXvthgNDApOZR0KmKi46DSK4jEzwgXlJAkpwPiK6xZ8ev5icHMwkJ36FWuKBj7coRxLMqgdqVwTFQzYbNU8aidIM7VvDFFzcjCOgjkSbJ0u7wzgjv/sw/PcKcwH9W4TL8S54Uc3c4dNd0zg2k9y20bZYVtab0eWs2gPluktWf2UHCIlz7QolnZjpPmpAJapQwaJg1Wi/R+DH2q/f9PptLZWEgWHCGVyV8rsWVgFtzjzZ3XTTe2RfUeSbVvlBN/LA95S1sNboQEZV/2h1Wcgswc+FcQ/Z3zxwcWRe45arv33iwXA9mC5tNbVQ==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=T8n/oM4xfKJCQ2vaF62Y9UKRCP5z2VP9hqwPpuG6tv7PRJwVEuXf5xOshz+dkOSQPTcuwjtLCpxxt+6CsWSTg1L641scsrBOWm7BOC3legXg8zHUXYY6h+tzefqeSvaVh+wr8gs3JtOvC5nLnkfJdcWKQG7NdffprRfm6ePBPUGz7g7cgv2/XLbpyq/bjVPT3EdL2x+hJdlDX8wDuLKlxPv9igAQ7h5X06YJ3105hJCqRn+S7coUlby6edB2On4hYylQWXs+eQNj4S6Tx6/TpUkEE9IcKcPf0+mmy1qpt2GCpNsNBsUzgHxHo0rNKm28PJaD/+YeouAddlkot9SYTA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SBCzh6AvmYjD33aRA68sl92McKlu1ZVjtsLMryayDN2w1a5gpJXeW4fZQ0zdcsTeYfHrXrAvPzbwR8Py8ZGbKcir5RGwNeyAMBwpGFz1HY8LeDltP/C0FeycTd5SsiyKPw1MCtaEw/M+aUHTS3QtU3qehU9Nkl12FUI3uHCpCtOXtwe993iXOYp3OsBp1a+VSvMqlJ3cKjNLRfDceTWhEf6yiBOHtSOvgrQHjzw/LOZqxRuETvdLQgU4bTN8vZrsgZiKuOOqZMvjxz5k0R2mSlTxXG01yjou5vmMxyLo8IIp9QTn/OQYhA5+eMjswDIdDIJh2emG2JNUqzRF/uxBUg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Julien Grall <julien@xxxxxxx>, Andrew Cooper <amc96@xxxxxxxx>, Lin Liu <lin.liu@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>
  • Delivery-date: Wed, 11 May 2022 14:16:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYZFb+rXOikPJI0E2wxRXQiKvDPK0X7v0AgAAFDwCAAAI1AIAABM2AgAADuACAAQJtAIAAuZCA
  • Thread-topic: [PATCH v3 4/6] xen: Switch to byteswap

Hi,

> On 11 May 2022, at 04:12, Stefano Stabellini <sstabellini@xxxxxxxxxx> 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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.