Re: [PATCH 1/7] byteorder: replace __u16

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 31/10/2024 11:23 am, Jan Beulich wrote:
> On 16.10.2024 11:37, Jan Beulich wrote:
>> On 09.10.2024 15:34, Jan Beulich wrote:
>>> On 09.10.2024 15:20, Andrew Cooper wrote:
>>>> On 09/10/2024 10:21 am, Jan Beulich wrote:
>>>>> In {big,little}_endian.h the changes are entirely mechanical, except for
>>>>> dealing with casting away of const from pointers-to-const on lines
>>>>> touched anyway.
>>>>>
>>>>> In swab.h the casting of constants is done away with as well - I simply
>>>>> don't see what the respective comment is concerned about in our
>>>>> environment (sizeof(int) >= 4, sizeof(long) >= {4,8} depending on
>>>>> architecture, sizeof(long long) >= 8). The comment is certainly relevant
>>>>> in more general cases. Excess parentheses are dropped as well,
>>>>> ___swab16()'s local variable is renamed, and __arch__swab16()'s is
>>>>> dropped as being redundant with ___swab16()'s.
>>>>>
>>>>> With that no uses of the type remain, so it moves to linux-compat.h.
>>>>>
>>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>>> ---
>>>>> I'm unconvinced of the need of the separate ___constant_swab16(). I'm
>>>>> also unconvinced of the need for said constants (that even had casts on
>>>>> them).
>>>> There is a still-good series deleting the whole of byteorder/ and
>>>> replacing it with a few-hundred line single header.
>>>>
>>>> It is the second thing stalled on a governance change (prohibited
>>>> reasons to object to a change) which clearly no-one gives a damn about
>>>> fixing.  In fact double spite because it denied a good engineer his
>>>> first changes in Xen.
>>>>
>>>>
>>>> I don't particularly feel like trying to polish byteorder.  I'm inclined
>>>> to rebase+repost Lin's patches, at which point the majority of this
>>>> series simply disappears.
>>> I wouldn't mind you doing so, as long as that other series then progresses.
>>> What I don't want to get into is the other series being stuck rendering this
>>> one stuck, too. Then it would imo be better to take this one first, rebase
>>> the other on top, and work towards it becoming unstuck (whatever that takes;
>>> I have no recollection of what the issue was back at the time, all I recall
>>> is that, yes, there was such work at some point).
>> Just to have a clear picture: Was your reply an objection, with you indeed
>> meaning me to hold back this tidying work? If so, can you please indicate
>> when, at least roughly, you mean to re-post what you think wants re-posting?
>> If not, can you please indicate so, for me to commit stuff that's otherwise
>> ready to go in (and which that other work should be easy to re-base over)?
> Just to mention here - short of an answer I'm going to commit this with the
> R-b from Frediano that I've got.

nack.

The reason there's even anything to do here is, in part, because you
were obstructive to Lin's series.

It wasn't only you, but the maintainers (plural) behaviour on that
series was so outrageous that it started the effort to governance to
prohibit certain classes of feedback, to make Xen a less toxic place to
contribute to.

I will get to it when I get to it.   You can use the time to reflect on
how you could have been more helpful in the past, and avoided this whole
issue.

~Andrew