From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: linux-kernel <linux-kernel@vger.kernel.org>,
<linux-kbuild@vger.kernel.org>
Cc: "Balbi, Felipe" <balbi@ti.com>
Subject: Kconfig "softdepends" idea
Date: Tue, 30 Apr 2013 12:52:50 +0300 [thread overview]
Message-ID: <517F9472.2030106@ti.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]
Hi,
I have an idea to improve the Kconfig dependencies, especially for
subsystem maintainers. First a bit of history:
I recently changed the Kconfig rules for omapdss driver to not depend on
OMAP platform, as the driver itself uses no OMAP specific APIs, and can
be compiled fine on, say, x86.
This got nack'ed by Linus, as omapdss is used only on OMAP, and allowing
it to be visible for other platforms is just extra clutter. I think
that's a valid point.
However, I think there are valid cases to allow a driver to be compiled
for other platforms. First two are quite minor, but I think the third
one is a major use case. I say here "omapdss" but you can replace it
with any driver that has build dependency to some platform.
1) Building omapdss with arm compiler should show all relevant warnings,
but in reality it seems that the compilers for different architectures
have slightly different behaviors. Building omapdss with a compiler for
other architecture is a good way to check for any possible errors. Also,
direct arch dependencies in a driver are generally a mistake, and
compiling with another compiler would bring these issues up.
2) When developing a new SoC, the IP in question could be in a, say,
FPGA board, attached to a PC. The same driver would thus be needed for
x86 also.
3) When making changes which affect drivers for multiple platforms (say,
fbdev changes), it is very difficult to compile test the changes. I
recently made changes to a bunch of fb drivers, and I think I managed to
compile only a few of them. To compile them all, I'd need to install all
the various cross compilers and find out which kind of kernel config is
needed to get the driver enabled.
If, on the other hand, the drivers would only depend on things they need
to get compiled, it gets much easier to compile test.
So, my idea is to have a new kind of Kconfig dependency. I'll call it
"softdepends" in lack of better name. A driver maintainer could use
"softdepends on ARCH_OMAP", instead of "depends on ARCH_OMAP", to say
that this driver does not actually build depend on ARCH_OMAP, but for
all normal purposes it does.
Normally, this would result in the same behavior as the normal
"depends", and Linus would not get a questions whether he wants to
enable this OMAP specific driver or not, and the driver would not be
visible on the menuconfig.
But the user could enable the driver if he explicitly so wants. Perhaps
a Kconfig option such as "ignore softdepends", enabling of which would
allow the user to enable the drivers that use softdepends. Or, maybe
just require the user to add the config option manually into his .config.
Now, I don't have much knowledge of the Kconfig internals, so the above
implementation ideas are just rough ideas to show the point.
Thoughts?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next reply other threads:[~2013-04-30 9:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-30 9:52 Tomi Valkeinen [this message]
2013-04-30 10:24 ` Kconfig "softdepends" idea Sam Ravnborg
2013-04-30 10:33 ` Felipe Balbi
2013-04-30 11:10 ` Tomi Valkeinen
2013-04-30 11:40 ` Sam Ravnborg
2013-04-30 12:01 ` Tomi Valkeinen
2013-04-30 11:36 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=517F9472.2030106@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=balbi@ti.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox