[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: Kconfig vs tool chain capabilities
On 25.08.20 14:44, Bertrand Marquis wrote: On 25 Aug 2020, at 13:37, Jürgen Groß <jgross@xxxxxxxx> wrote: On 25.08.20 14:20, Bertrand Marquis wrote:On 25 Aug 2020, at 12:22, Jürgen Groß <jgross@xxxxxxxx> wrote: On 25.08.20 13:16, Bertrand Marquis wrote:On 25 Aug 2020, at 12:06, Jürgen Groß <jgross@xxxxxxxx> wrote: On 25.08.20 12:17, Bertrand Marquis wrote:On 25 Aug 2020, at 10:49, Jürgen Groß <jgross@xxxxxxxx> wrote: On 25.08.20 10:48, Jan Beulich wrote: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 commandsWhile 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.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. They are silently disabled. Just like CET in case of an incapable tool chain. 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. In case we as developers have a special test case then we need to check the .config whether the desired settings are really present. Having those settings depending on tool capabilities in a specific file will make this check much easier. 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). We can't have everything and I believe automatically disabling features which can't work with the current tools is a sane decision. Doing this via Kconfig is the better approach compared to Makefile sniplets IMO.That sounds like a nice feature to have some compiler or tools options that can be selected or activated in Kconfig. There are some compiler options mandatory to handle some erratas or XSA that one might want to explicitely select. I am bit unsure about the part where some kconfig options would only be available or not depending on some tests with the compiler being doing prior to opening the editor. I would guess the menuconfig process would have to first run some tests and then generated some HAS_ configuration options depending on the result of the tests. Did i got the idea right here ? Is this something somebody tried to do ? As a user I would more expect that the build process would tell me that my configuration is invalid because i selected something that is not supported by my compiler. I might have the chance to just fix my build to use the right compiler (like by mistake using x86 toolchain to compile for arm). We should also be careful not to silently ignore some configuration option if one is changing the compiler and the new one does not support an option. A user would have his configuration and compile using it without passing through the editor interface and might need to be aware that a part of his configuration is not valid anymore because the tools he is using changed. This is something that could occur a lot when using a distribution toolchain. Also there are some compiler option changing so i would more think that there should be generic configuration options so that in the makefiles we could have the opportunity to add different compiler options for different toolchains depending on the version or the type of the toolchain. To be clear i would see something like: in kconfig: COMPILER_OPTION_XXX bool “activate XXX compiler flag in Makefile: ifeq ($(CONFIG_COMPILER_OPTION_XXX), true) test_compiler_cxx: $(CC) -xxx dummy.c -o dummy || $(error Your compiler does not support -xxx) cc-flags += -xxx endif The syntax is wrong here but you get the idea :-)Ah, okay, this is another approach, which might be even more flexible. It would allow to control compiler flags instead of more high level features.We might have both, this would also allow to have more high level features which are doing both adding compiler flags and other stuff,In case we want to go that route we should default COMPILER_OPTION_XXX to the current tool capabilities in order to avoid longer try-and-error loops.I am not quite sure how you want to achieve this cleanly.Something like (picked an actual example from x86): config HAS_COMPILER_OPTION_IBR bool "Select compiler option -mindirect-branch-register" default $(cc-option,-mindirect-branch-register) blah blah blahNice :-) Definitely i would add a “default y if EXPERT” or something equivalent.Uh, rather not. I as a developer don't want to have change the config manually just because a new HAS_COMPILER_OPTION_ has been added my tools don't understand (yet). The default action should require no user intervention, even as expert.I agree with the argument. Maybe we could have an other option like DISABLE_COMPILER_CHECK for this. I would rather have my test system fail with a make error by setting this then silently discard the option if my compiler is modified. But this would exactly be the behavior. A new HAS_COMPILER_OPTION_ added would default to your tool capabilities and you could change it manually afterwards. If you change it to "y" in spite of your tools not supporting it the build would fail. And if it would be "y" per default initially the .config file would be created with the option enabled, so a tool change removing support of the option would result in a failed build, too. Juergen
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |