[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/7] byteorder: replace __u16
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |