Hi Jeff, On Tue, 23 Feb 2016 08:16:40 -0500, Jeff Mahoney wrote:
On 2/23/16 6:04 AM, Jean Delvare wrote:
Le Monday 22 February 2016 à 14:12 -0500, Jeff Mahoney a écrit :
Yep. That's the reason I left it enabled but disabled (I think) the individual drivers.
Yes you did. Ideally these individual drivers wouldn't even show up (I've just sent a patch upstream to achieve this.)
Good luck. Seriously. Having to sort out which drivers belong to ARM and which don't is a big part of the time involved in updating the configs, and one that I'm not particularly motivated to get "perfect" given the time involved and the downside if I miss one (a few kiB wasted disk space). Others have tried to mark things as depending on ARM in the past only to be rebuffed by specious claims of "build coverage."
I imagine the time it takes and this is why I am pushing upstream to get better. Jiri's TEST_COMPILE is normally enough to dismiss any complaint about build test coverage. I perfectly understand that you can only spend a limited time checking which drivers belongs to which architecture. Whenever I report a configuration option that could be improved, I do not mean to blame you for not doing it, only trying to help you (and the community in general.)
My proposal to disable CONFIG_FPGA on non-arm has two motivations: 1* Don't build and ship the fpga-mgr core module when it serves no purpose. 2* Don't ask questions about future individual drivers, as the probability that we need them is very low. Again ideally they wouldn't show up on architectures where they serve no purpose, but in practice upstream is bad at this and I often have to sent patches to add the hardware dependency after the fact.
It's not just bad, it's *deliberately* bad, at least historically. Jiri Slaby (IIRC) introduced a TEST_COMPILE option as a sufficient dependency to allow building on non-ARM but it seems to be not well known. I'd love to see you find some success here.
Trying as much as I can. I hoped to set a trend but so far I do not have the impression that it's catching up (yet.) But I am patient and tenacious...
Point 2 is mostly Jeff's problem. As a user I care about point 1.
Sure it is possible, as Andreas wrote, that someday this subsystem is used for a more generic piece of hardware. But it might also never happen and then we build and ship a useless module forever. Also I would think that in the event where a useful driver would ever depend on CONFIG_FPGA, someone would figure it out and ask us to enable it. I see no benefit in anticipating this unlikely event.
One of the things I'd like to consider in the future is splitting the kernel package further. We have this wide swath of drivers that we enable on x86 because "some system out there could be using it" but in reality almost none of them are. Does every x86_64 machine out there need the full array of touchscreen drivers? SPI drivers? I2O? etc? Probably not.
Hey, this is a nice can of worms you have here, can you open it please? :D Seriously I'd love a lighter kernel package (3470 modules shipped with the Leap kernel...) but I can already imagine the endless discussions about which drivers should be included in the main kernel package and which should go to the extra modules package. Or if we go with a per-subsystem split, to what degree we should split. Or if we go with one package per driver. And how we handle dependencies. And how we get the packages installed automatically on systems which need them. And is the gain really worth the effort. So for now I am sheepishly going for low-hanging fruits: disabling drivers which are not usable at all, and modularizing the rest as much as possible. -- 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