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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan