Re: [Xen-devel] [PATCH 1/2] xen/mm: fold PGC_broken into PGC_state bits

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.03.2020 11:26, David Woodhouse wrote:
> On Thu, 2020-03-19 at 09:49 +0100, Jan Beulich wrote:
>> On 18.03.2020 18:13, David Woodhouse wrote:
>>> The -MP makefile patch I posted yesterday... I almost didn't bother.
>>> And when I allowed myself to be talked into it, I was entirely
>>> unsurprised when a review came in basically asking me to prove a
>>> negative before the patch could proceed. So as far as I can tell, it'll
>>> fall by the wayside and the build will remain broken any time anyone
>>> removes or renames a header file. Because life's too short to invest
>>> the energy to make improvements like that.
>>
>> So are you saying that as a maintainer I should let go uncommented a
>> change which I'm unconvinced doesn't have negative side effects,
>> besides its positive intended behavioral change? The more that here
>> the workaround is rather trivial? As you may imagine, I've run into
>> the situation myself a number of times, without considering this a
>> reason to make any adjustments to the build machinery.
> 
> Jan, I would respectfully request that you take another look at your
> initial response, but put yourself in the shoes of a patch submitter:
> https://lists.xenproject.org/archives/html/xen-devel/2020-03/msg01171.html
> 
> You mention a "simple" workaround... but the workaround I've been using
> is to manually remove the offending .o.d files, one at a time (or at
> least one directory at a time), until the broken build starts working
> again. Is that what you meant? And you really didn't ever consider that
> it should be fixed?

No, the workaround I've been using (after initially doing the expensive
one you describe) was to simply put in an empty file (or perhaps one
with an #error directive) in the place of the deleted one, rebuild, and
all .*.o.d files would have been updated. I might do so even before
fully deleting the file.

> And the substance of the response is basically saying "this is voodoo
> and we can't touch it or unspecified things might break, but I have no
> idea where to tell you to look."
> 
> Looking back I realise that the concern about phony rules overriding
> pattern rules didn't even come from you; your concern was more nebulous
> and unaddressable. It looks like I came up with a straw man and shot
> *that* down in my later analysis (although that wasn't my intent; I
> think the concern about pattern rules really did come from somewhere).
> 
> You asked a question about "why isn't this default behaviour", which is
> kind of a silly question when asking about an option (-MP) that was
> added to GCC almost a decade after the initial -MD behaviour was
> established. Of *course* they didn't retroactively change the default.

I don't see at all why this would be "of course" - if there really
was no undue side effect, why couldn't they?

> Read that message again from the point of view of a contributor.
> Pretend it isn't even me; pretend it's someone attempting to make their
> first, trivial, improvement to the Xen ecosystem.
> 
> I hope you'll understand why my initial reaction was just a
> monosyllabic 'no'.

To be honest- no, I don't. I didn't say "no way". Instead I asked
back to see whether there's more background to this. It is a useful
piece of information to know that -MP post-dates -MD by 10 or more
years. It's still speculation of why a new option was added rather
than making this default behavior, but I feel less afraid of the
change this way than by an implied "this not going to do any harm"
without really being certain why there is a separate option in the
first place (and gcc doc also not saying anything to this effect).

I can certainly follow your sentiment, not the least because
especially in my early days I also frequently got back replies I
didn't like, in various projects. Yet in a case like this one I'm
afraid it is not the reviewer's job to point out the unsafety of
a change, but it's the submitter who has to (sufficiently) prove
that a change won't break anything. Yes, in the typical case,
when there's a recognizable bug, the reviewer would point this
out. But there are cases where there's no obvious bug, but
experience (and, as so often, insufficient documentation) tells
one to be wary of changes of, possibly, any kind.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel