[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kconfig vs tool chain capabilities



On 25.08.20 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:
On 25.08.20 08:31, Jan Beulich wrote:
1) Does it make sense for tool chain capabilities to be recorded?

2) Does the recording actually work reliably?

As to 1), I'm personally of the opinion that the original model
was the better one, even if I can see advantages from downstream
(distro in particular) pov. Yet even for them it may mean they
would not get presented certain options which they may want to
enable, if only they knew they'd need to upgrade their tool
chain. For developers otoh, I don't think this model is a helpful
one: They absolutely should be aware of pieces they end up not
building (and which hence they're also not going test).

(I'd like to note that there may certainly be cases where during
the building of the tree features get enabled/disabled by other
means without the person doing the build becoming aware. I think
such should equally be converted to Kconfig selections, with the
build simply failing if tool chain prereqs aren't met. The
typical case though is a choice between different ways of
generating code, with no effect on resulting functionality
beyond a possible difference in performance.)

Additionally the answer to 2) is, I'm afraid, continuing to be
"No", as there is - afaict - no way for a once recorded .config
to get updated if the underlying tool chain changed. All options
to overcome this that I have been able to think of so far
(unconditional invocation of kconfig; hashing of involved [tool
chain] binaries) come with a pretty heavy overhead on build time
and/or other complications.

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? Why aren't you concerned that you can't configure
ARM-specific options in an x86 build then?

My model will allow to give the user a hint that something has happened
which will likely have some impact on the hypervisor configuration. It
would even be possible to automatically run "make oldconfig" and print
the resulting diff of .config and .config.old, and maybe even allow the
build to continue if nothing but the tools capabilities/versions have
changed.

One other remark:

We can still introduce an config option CONFIG_IGNORE_TOOL_CAPABILITIES
allowing to specify options not supported by the tools.


Juergen



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.