Le Tuesday 27 May 2014 à 09:32 -0400, Jeff Mahoney a écrit :
-----BEGIN PGP SIGNED MESSAGE-----
On 5/21/14, 9:50 AM, Jean Delvare wrote:
Le Tuesday 20 May 2014 à 22:37 +0200, Alexander Graf a écrit :
On 20.05.14 22:21, Jean Delvare wrote:
So may I disable CONFIG_RTC_DRV_MOXART from all
I usually go through things that can be set as =m
activate them to have as much hardware support available as
Well, please stop doing that ;-) Upstream is notoriously bad at
limiting drivers to the systems on which they are actually useful
(or maybe they are not that bad but still not good enough to my
taste.) So in many cases new drivers are only needed in a subset of
our kernels, or even none of them.
It's on purpose and it's infuriating. I've tried to submit patches to
narrow hardware support to platforms which can actually use it and
have been refused due to "build coverage." What use build coverage is
when the hardware will never run on it is beyond my comprehension, but
I just let it drop.
This must have been before Jiri Slaby introduced COMPILE_TEST as an
alternative dependency. I'm really only building on top of this
excellent initiative from Jiri. With that you can easily turn down the
"build coverage" argument. I did, and it worked each time. Apparently a
number of upstream developers didn't know about COMPILE_TEST yet.
Hopefully with the bunch of patches I'm sending these days, everybody
will know about it soon enough :-)
After discussing with Laurent Pinchart who supports the idea of a wider
use of COMPILE_TEST, we converged to the term "run-time Kconfig
dependencies" for that. Laurent also suggested splitting the regular
build-time dependencies and run-time dependencies on different "depends
on" lines, in order to make things clearer, and I completely agree.
I would like to document all this somewhere upstream but for now I
couldn't find in which documentation file this would better go. Laurent
suggested somewhere under Documentation/kbuild but I'm afraid kernel
contributors don't look there.
I know it
takes some time to decide for each new driver whether it
should be enabled or not. But it pays quickly by reducing the risk
of build failure (which in fact are sometimes a hint that you
enabled the driver on an architecture it wasn't meant for, so it
was never tested) and speeding up the future builds and updates.
Thanks again for all your work here. Seeing how much effort you've
needed to put into it has pushed me to start more aggressively
documenting config changes in the commit messages. The
config-options.txt attempt was a nice idea, but it fell apart pretty
I agree. I too thought that config-options.changes was a great
initiative, but I have to admit that even me do not maintain it
properly. It takes additional work and time to update it, and you have
to remember to do it. And handling that kind of file over multiple
branches isn't always trivial. Hey, there's a reason why we killed
Good commit messages are the way to go. Once you're used to that, you
stick to that good habit. And git makes it relatively easy to find the
Hopefully this won't. If something was enabled
because it's a
new driver and looked sane, I'll document it as such. I've started
doing a bit of research on whether hardware is supported on a
particular arch, but sometimes it can be a dead end: How does one know
if a PCI device will only ever be found on e.g. ppc64? Even if it's
only initially shipped there, it can be recycled into other hardware
In most cases you don't know. Really upstream has to document it.
For now my preference goes to not enabling drivers when we're not sure.
If something is missing, people will complain. If something is included
but useless, nobody will tell and we'll keep building, packaging,
shipping and installing useless drivers on millions of systems for 10
I'd like to get other folks on board with this.
Hopefully with a
standard format moving forward (it doesn't need to be what I'm doing
now, but it seemed sane.)
I'm on-board already. I chartered the boat actually ;-)
SUSE L3 Support
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org