Re: [PATCH 3/4] build: also check for empty .bss.* in .o -> .init.o conversion

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.08.2020 19:51, Andrew Cooper wrote:
> On 07/08/2020 16:40, Jan Beulich wrote:
>> On 07.08.2020 17:12, Andrew Cooper wrote:
>>> On 07/08/2020 11:56, Jan Beulich wrote:
>>>> On 06.08.2020 18:16, Andrew Cooper wrote:
>>>>> On 06/08/2020 10:05, Jan Beulich wrote:
>>>>> Can't we remove all of this by having CONFIG_XEN_PE expressed/selectable
>>>>> properly in Kconfig, and gathering all the objects normally, rather than
>>>>> bodging all of common/efi/ through arch/efi/ ?
>>>> _If_ we settle on Kconfig to be allowed to check compiler (and linker)
>>>> features, then yes. This continues to be a pending topic though, so
>>>> the switch can't be made like this at this point in time. (It could be
>>>> made a Kconfig item now - which, when enabled, implies the assertion
>>>> that a capable tool chain is in use.)
>>> I am still of the opinion that nothing needs discussing, but you are
>>> obviously not.
>>>
>>> Please raise this as a topic and lets discuss it, because it has a
>>> meaningful impacting on a large number of pending series.
>> Preferably I would have put this on this month's community meeting
>> agenda, but I'll be ooo next week, so that's not going to help, I'm
>> afraid. I guess I should put it up in email form when I'm back,
>> albeit I wasn't thinking it should need to be me to start the
>> discussion. Instead my view was that such a discussion should (have
>> been, now after-the-fact) be started by whoever wants to introduce
>> a new feature.
> 
> It would have been better to raise a concern/objectection before you
> committed the feature.

I did, and I committed the whole lot because of not wanting to block
the many improvements over this one aspect I disagree with. Recall
me asking what happens if the compiler (or any part of the tool chain)
gets upgraded (or, possibly worse, downgraded) between two
(incremental) builds?

> It was a very clear intent of upgrading Kconfig and switching to Kbuild,
> to clean up the total and chronic mess we call a build system.  It has
> been discussed multiple times in person, and on xen-devel, without
> apparent objection at the time.

The change to Kbuild was discussed. The use (and, depending on how one
views it, abuse) of Kconfig to determine tool chain capabilities wasn't,
iirc. At least not in a way that it would have been noticeable to me.

> The state of 4.14 and later is that we have the feature, and it is
> already in use, with a lot more use expected to continue fixing the
> build system.

If I'm not mistaken I did make my ack on the first use of the new
behavior (in your CET series) dependent upon a subsequent discussion
(that should have occurred up front), again in an attempt to get
certain things taken care of for 4.14. This was, again iirc, in turn
referring to the earlier ack on Anthony's series, which was given in
a similarly conditional manner. (But I may be mis-remembering.)
Therefore ...

> You are currently blocking work to fix aspects of the build system based
> on a dislike of this feature, *and* expecting someone else to justify
> why using this feature as intended is ok in the first place.

... I'm pretty puzzled: Am I now being told that I shouldn't have
made the compromises, and rather should have blocked things earlier
on? I.e. is my attempt to show reasonable behavior now being turned
back into an argument against me? If so, I can certainly draw the
obvious conclusions from that, for the future.

> I do not consider that a reasonable expectation of how to proceed.
> 
> If you wish to undo what was a deliberate intention of the
> Kconfig/Kbuild work, then it is you who must start the conversation on
> why we should revert the improvements.

If I hadn't voiced my reservations long before, this _may_ indeed be
a valid position to take. But given all that had been said already
before any of this went in, I don't think it is. Anyway - despite me
not thinking it should be me (and hence it not having happened so
far), I intend (as said) to start a discussion. To be honest, I'll
be curious to see how it'll go, both in terms of number of
responses received and in terms of everyone honoring the fact that
it should _not_ matter that the logic in question was already
committed.

Jan