Re: Kconfig vs tool chain capabilities

[Jürgen Groß <jgross@xxxxxxxx>]

On 25.08.20 14:08, Jan Beulich wrote:
> 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.
Yes, that's what I'm saying. Still you might do a change requiring to
touch those files.

And CET can't be enabled at all with old tools.

> > 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.
There are only certain kinds of "depends on" which _you_ regard to be
problematic. Other people might regard other "depends on" to be
problematic. And probably most people won't regard any "depends on" to
be problematic.

I absolutely understand that in some cases you need to perform extra
checks and changing the current behavior would make it easier for you.
I suspect, though, that such a modification would impose additional
work for most users, so I think the benefit of many is more important
than the benefit of very few developers hit by this issue.

Going the route Bertrand has suggested (with my suggested addition)
might be a nice compromise, though.


Juergen