Re: Kconfig vs tool chain capabilities

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.08.2020 10:08, Jürgen Groß wrote:
> On 25.08.20 09:48, Jan Beulich wrote:
>> On 25.08.2020 09:43, Jürgen Groß wrote:
>>> On 25.08.20 09:34, Jan Beulich wrote:
>>>> On 25.08.2020 09:12, Jürgen Groß wrote:
>>>>> I think both problems can be solved at the same time via the following
>>>>> approach:
>>>>>
>>>>> - collect the data which is reflected in today's CONFIG_ variables in a
>>>>>      single script and store it in a file, e.g in a format like:
>>>>>
>>>>>      CC_IS_GCC y
>>>>>      GCC_VERSION 70500
>>>>>      CLANG_VERSION 0
>>>>>      CC_HAS_VISIBILITY_ATTRIBUTE y
>>>>>
>>>>> - check the tool data at each build to match the contents of that file
>>>>>      and either fail the build or update the file and rerun kconfig if 
>>>>> they
>>>>>      don't match (I think failing the build and requiring to run a
>>>>>      "make config" would be the better approach)
>>>>>
>>>>> - fill the CONFIG_ variable contents from that file in kconfig instead
>>>>>      of issuing the single shell commands
>>>>
>>>> While I agree this is a possible model to use (but still not the
>>>> one we've inherited from Linux), I fail to see how this addresses
>>>> my "developers should be aware of what they do (not) build and
>>>> test" concern: There'd still be dependencies of Kconfig options
>>>> on the tool chain capabilities, and their prompts therefore would
>>>> still be invisible without the tool chain having the needed
>>>> capabilities. IOW I only see this to address 2), but not 1).
>>>
>>> Sorry, I fail to see a problem here.
>>>
>>> What sense does it make to be able to configure an option which the
>>> tools don't support?
>>
>> Take CET as an example (chosen because that's the one which
>> already uses the Kconfig approach, despite my disagreement): It's
>> quite relevant to know whether you're testing Xen with it enabled,
>> or with it disabled (and hence you potentially missing changes you
>> need to make to relevant code portions).
> 
> Correct me if I'm wrong, but assuming my suggested changes being made,
> wouldn't a .config file setup once with CET enabled (and I assume you'd
> try to enable CET on purpose when trying to test CET and you'd realize
> not being able to do so in case your tools don't support CET) ensure
> you'd never been hit by surprise when some tool updates would remove
> CET support?

Probably, but that's not my point. With a CET-incapable tool chain
you're not prompted whether to enable CET in the first place, when
creating the initial .config. It is this unawareness of a crucial
part of code not getting built and tested (and likely unknowingly)
that I dislike. In fact, after Andrew's patches had gone in, it
had taken me a while to realize that in certain of my builds I don't
have CET enabled (despite me having done nothing to disable it), and
hence those builds working fine are meaningless for any changes
affecting CET code in any way.

Jan