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

Re: Kconfig vs tool chain capabilities



On 25.08.20 08:31, Jan Beulich wrote:
Hello,

while the (ongoing) migration to Linux'es Kbuild has brought (and
will continue to bring) quite a few good improvements, there's one
aspect that was - afaict - slipped in without any prior mentioning
and discussing. This mail is meant to serve as a starting point to
have such a discussion "after the fact". The implication is that I
expect there to not be an argument along the lines of "is already
in the tree". In fact one or two of my acks for related patches
were made dependent upon such a discussion to happen, without a
preset outcome.

I'd also like to ask to avoid an argument of "Linux is doing so,
hence we should do so, too". We really ought to form our own
opinion rather than "blindly" inheriting whatever they do.

The issue is the intended recognition and recording of tool chain
capabilities. Until now I'm unconvinced this is the intended
purpose of Kconfig, unlike user land's typical ./configure. The
latter serves to interrogate the system of available functionality,
including but not limited to tool chain capabilities. Admin
overrides to this are possible via --enable*, --disable*, or
--with* kinds of options handed to the script.

As opposed, Kconfig traditionally has served as merely a tool to
collect (build) admin decisions, recording them as well as derived
data. The implication was that the person doing the configuration
was responsible to ensure that selections requiring special tool
chain capabilities would be enabled only if the tool chain used
was actually capable of dealing with the involved code.

Therefore I see two questions that need answering before either
making more wide spread use of the new functionality, or before
undoing the present uses and returning back to the original model:

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


Juergen



 


Rackspace

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