Hi Alex, 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 out kernels?

Yes, please.

Done.

I usually go through things that can be set as =m and just activate them to have as much hardware support available as possible :).

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. 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, -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Hi Jeff, Le Tuesday 27 May 2014 à 09:32 -0400, Jeff Mahoney a écrit :

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 5/21/14, 9:50 AM, Jean Delvare wrote:

...

Hi Alex,

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 out kernels?

Yes, please.

Done.

...

I usually go through things that can be set as =m and just activate them to have as much hardware support available as possible :).

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 quickly.

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 kernel-source.changes... 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 information.

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 later.

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 years.

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 ;-) -- Jean Delvare SUSE L3 Support -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org