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
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
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
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?
Hey, this is a nice can of worms you have here, can you open it
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
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