[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 1/7] byteorder: replace __u16
On 31.10.2024 13:20, Andrew Cooper wrote: > 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. Too late. > 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. Do you really think that with this kind of reply you do any better than what you complain about in my (supposed) earlier behavior? I can't help the impression that you simply can't live with views differing from your own in certain cases. If you have specific, reasonably objective comments on that past communication (which I no longer have to hand), I may certainly try to do better in the future. Blanket statements like those above simply aren't actionable (and wording-wise close to a conduct violation imo). Jan
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |