Re: Kconfig vs tool chain capabilities

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.08.2020 11:49, Jürgen Groß wrote:
> On 25.08.20 10:48, Jan Beulich wrote:
>> On 25.08.2020 10:08, Jürgen Groß wrote:
>>> 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.
> 
> Yes, this is the result of letting some options depend on others.
> 
> This is what I meant regarding the architecture: there are e.g. multiple
> source files in drivers/char/ being built only for ARM or X86, in spite
> of being located outside arch/. And yet you don't see this as a problem,
> even if you are not able to select those drivers to be built when using
> "the other" arch.

But they can't be enabled at all on x86.

> So IMO either we ban "depends on" from our Kconfig files (no, I don't
> want to do that), or we use it as designed and make it as user friendly
> as possible.

"depends on" can be quite useful without hiding anything from the
person configuring Xen: You can have dependent features be disabled
by disabling a top level feature (via answering a respective prompt).
There are only certain kinds of "depends on" which are problematic in
this regard.

> And BTW, I can't see how setting the tolls' capabilities from e.g.
> arch/x86/Rules.mk is better in any way (see how CONFIG_INDIRECT_THUNK
> got its value in older Xen versions like 4.12).

I've alluded to this not being any better in my initial mail.

Jan