Re: [PATCH] x86/mem: Make mem_hotadd_check() more legible

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.07.2023 14:54, Alejandro Vallejo wrote:
> On Wed, Jul 19, 2023 at 02:09:55PM +0200, Jan Beulich wrote:
>>> [1] The hand-crafted alignment there is going to collide with the efforts
>>> to integrate automatic style checkers. It's also not conveying critical
>>> information, so I'd argue for its removal in the spirit of making future
>>> diffs less intrusive.
>>
>> ... I don't agree here. First of all I don't see why this should
>> make style checking harder. There's nothing written anywhere that
>> such alignment padding isn't allowed in our code, so any checker
>> we want to use would need to tolerate it. Plus while such padding
>> doesn't convey critical information, it still helps readability.
>>
> Considering the last Xen Summit sessions I think it's reasonable to assume
> we do want automatic style checking to become a reality. If we want an
> automatic style checker to be eventually introduced I think we should be
> mindful of style changes unlikely to be captured by _any_ policy we may end
> up having. In particular, alignment of arguments across different
> statements on different functions/macros is unsupported on (most?) major
> style checkers, and that's highly unlikely to ever change.
> 
> In particular, any style checker must follow strict rules in order for it
> to yield consistently deterministic results (otherwise it might suffer from
> termination issues). Expecting a style checker to automatically generate
> heuristics that happen to match our current code configuration is not a
> realistic goal, I reckon.

I wasn't thinking of heuristics. I also wasn't expecting a style checker
to actually request adjustments to insert padding where may (seem to be)
missing. What I would expect is that it also doesn't point out such
seemingly excessive padding, requesting it to be dropped. I'll admit that
this may lead to the checking being slightly less useful, because of
potentially not pointing out an issue where there is one, but that would
still seem better to me than involving heuristics.

Jan

> In this sense, having a guideline (i.e: not a rule) about trying to avoid
> hand-crafted alignment where the benefit of it is not critical would be
> good. In the spirit of making a complicated problem simpler rather than...
> well, complicated.
> 
> Alejandro