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
