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

[Frediano Ziglio <frediano.ziglio@xxxxxxxxx>]

On Wed, Oct 9, 2024 at 2:34 PM Jan Beulich <jbeulich@xxxxxxxx> 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).
>
> Jan
>

I usually don't like stopping a series waiting for another series too.

In these mostly automated large changes instead of a manual rebase I
extract patches with "git format-patch", do the same automated replace
with sed/perl (like "s/\<u32\>/uint32_t/" and so on) and apply with
"git am".

My 2 cents.

Frediano