Hi Jeff, all, CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK? 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
On Mon, 2016-02-22 at 14:58 +0100, Jean Delvare wrote:
Hi Jeff, all,
CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK?
Sounds reasonable to me.
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
Am 22.02.2016 um 15:46 schrieb Matthias Brugger:
On Mon, 2016-02-22 at 14:58 +0100, Jean Delvare wrote:
Hi Jeff, all,
CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK?
Sounds reasonable to me.
Matches my understanding, Altera and Xilinx SoCs are the only affected platforms I'm aware of - both being armv7hl default/vanilla (Cortex-A9) and, if available yet, arm64 default/vanilla (Cortex-A53). I could imagine someone implementing a driver for some FPGA-equipped, e.g., PCIe card on any architecture, so if you disable the subsystem now, you may want to recheck that at some point, as you won't notice in oldconfig then. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/22/16 2:10 PM, Andreas Färber wrote:
Am 22.02.2016 um 15:46 schrieb Matthias Brugger:
On Mon, 2016-02-22 at 14:58 +0100, Jean Delvare wrote:
Hi Jeff, all,
CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK?
Sounds reasonable to me.
Matches my understanding, Altera and Xilinx SoCs are the only affected platforms I'm aware of - both being armv7hl default/vanilla (Cortex-A9) and, if available yet, arm64 default/vanilla (Cortex-A53).
I could imagine someone implementing a driver for some FPGA-equipped, e.g., PCIe card on any architecture, so if you disable the subsystem now, you may want to recheck that at some point, as you won't notice in oldconfig then.
Yep. That's the reason I left it enabled but disabled (I think) the individual drivers. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWy12AAAoJEB57S2MheeWypEcP/3D91hyf+0Dg3aBiIKzGKKe9 kye3/iSThGNtE03rr9HuJyIsQC+kEiSu1fZr0Aq/9cqJsHiYmS4FdhTukEidAvii sW00wLidMNZZdhzTmHN80CU4LSR48QoH5l1H2dItOTMNNr7JtmGM9iLjOAORCWlP DW51tui05DRQ3f3BQJlVVojMqbrvvhXmFR2O6yVf+4qwCzcbdcagdB+OPXdW9W1B x9HcVY2GMM+Rz89cjzq4fEEbKA5BeZux58Dvzf4dwzWpDz6e0u5NwjSuKZ93gAlO QpNlaGwsjRvAJaj+8r3tEvOc4HHoJox6ymmpl5oPOTTSv52Ho1KShjfZ46LUJvd/ BFZMzgQ/ZPsNIAoZRFN8evxO19O1wCY8TTHWzElOFAvBZKkdu6zDtqxM+BspXsNa smaU219P3c40kX/ciY7zhMVSaScha8Ovs376JqHbOmTN8WynsMDk2V/LiQ+7Fgy9 VMZO5asd1tCF4h5eTJZYgNWTz1Ktz7FdHrKTysd6BmRjFogqZOPpdCsbgQFVY01Z yg0O37aLrsVkIERCtmggesuifU5CjJxBLryin65F8dJV2vRSGKlcOrmhWUudVLnM 8/Ywz2cpg49KWje1zsKqQsPRhTvHKC8o7/LuLZIOk5WJ0fCiNCumcUmFZLWK5o5+ E6R853/MDw7r+DehOxl+ =ZXvM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Hi Jeff, Andreas, Le Monday 22 February 2016 à 14:12 -0500, Jeff Mahoney a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2/22/16 2:10 PM, Andreas Färber wrote:
Am 22.02.2016 um 15:46 schrieb Matthias Brugger:
On Mon, 2016-02-22 at 14:58 +0100, Jean Delvare wrote:
Hi Jeff, all,
CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK?
Sounds reasonable to me.
Matches my understanding, Altera and Xilinx SoCs are the only affected platforms I'm aware of - both being armv7hl default/vanilla (Cortex-A9) and, if available yet, arm64 default/vanilla (Cortex-A53).
I could imagine someone implementing a driver for some FPGA-equipped, e.g., PCIe card on any architecture, so if you disable the subsystem now, you may want to recheck that at some point, as you won't notice in oldconfig then.
Everything can happen, but by this reasoning we would ship allmodconfig kernels ;-)
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.) 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. 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. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/23/16 6:04 AM, Jean Delvare wrote:
Hi Jeff, Andreas,
Le Monday 22 February 2016 à 14:12 -0500, Jeff Mahoney a écrit :
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2/22/16 2:10 PM, Andreas Färber wrote:
Am 22.02.2016 um 15:46 schrieb Matthias Brugger:
On Mon, 2016-02-22 at 14:58 +0100, Jean Delvare wrote:
Hi Jeff, all,
CONFIG_FPGA looks like something only useful on embedded systems, therefore I believe it should be disabled on all non-ARM architectures. As a matter of fact this subsystem only has 2 drivers are the moment, both for ARM. OK?
Sounds reasonable to me.
Matches my understanding, Altera and Xilinx SoCs are the only affected platforms I'm aware of - both being armv7hl default/vanilla (Cortex-A9) and, if available yet, arm64 default/vanilla (Cortex-A53).
I could imagine someone implementing a driver for some FPGA-equipped, e.g., PCIe card on any architecture, so if you disable the subsystem now, you may want to recheck that at some point, as you won't notice in oldconfig then.
Everything can happen, but by this reasoning we would ship allmodconfig kernels ;-)
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."
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.
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. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWzFu4AAoJEB57S2MheeWydEAQAKOdeFJAP92aMiWAhU8lZecG c1dE6i/bgN8EnDXm/w6jGaMmcx/RknEbdHV12S/xCuqb8Gnj9uJ35QydjwD4fGGr ub6jMK3NN+Dzf2qFLq3beMtGu/LcUr9CkvC6FBHmva8jMPlUXd1Z7MPtz6NhvGMS aHk8ptCY2NRhy9ZAHECPBXC+tFtSNh+FsjJwAp/AXgaxn0MEhEZb+ZqJAQzHUkl/ CLeDpmlZa2jmIXwykxznqeWz6nISif60M0CQODsNXHi4lAEg95pvJ6rG9xSh5fXn ftDcSeGP6DSvtBS6tzA2x9HMC2CM4ngKcWzg+52eefCoRLMeylQXx5gq4uclGOdn Tmm5rVXV9dUn/PYZMCsKTER7ywRhFho2NyUswkgz5JFUN+ozoeJrrMgnc38jd4vA oNj2g4LfDU+1zUa744t5No6HFAUhQwYf4x3vJKUKncsWa75OnxJpcRv1ES9T9ULE 5TnGhhtqai/IRQh13a08qLcxHQs4o9B/pf7oFm/Wbk+AHDVS1o+g0AamSj5szRzs G66SLs4Pl3v3Fd73vECKt8l4v0XCJKl6kvq4lcrVvxAlLRPDaw2SYR3VgclTSYIh Lu15MLUajNInAUYGYzyMdKExNs7eHnqCeFkNSFFhMeJTMa//E2kJmd5pC+HqWgg2 vUBn9wW0Bo++MauG0+Sf =B89l -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/24/16 8:23 AM, Jean Delvare wrote:
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.)
Oh, I don't take it as blaming or criticism. I really do appreciate the time you put into reviewing the configs.
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.
Heh, once upon a time I advocated for splitting up the kernel package to very small granularity so that if a particular was only interesting for a driver update, the user could take just that and know that the rest of the system was stable. The support reality for that is obviously a nightmare. And yeah, this conversation will inevitably devolve into bikeshedding. I'm not sure how to combat that in a fair way since, ultimately, it's all a judgement call. The down side is that by trying to make everyone happy, nobody is. I think we can assume that things like ARCNET, FDDI, Token Ring, etc are relatively rare these days. We already have a similar split with -base and we know there are things that may be usable in virtualized environments that we don't include there (other file systems, for example). That doesn't mean it hasn't been hugely useful for a lot of people. I can take a preliminary approach to it and post the results. I suppose an obvious question is what to call it? We already have -base, <unqualified>, and -extra for SLES. Do we want to use the -extra name and put everything uncommon in there or try to split it more? For the ARM teams, would you be interested in a kernel-default-$board? The same *base* kernel boots, which is the important bit, but then only the modules required for that system would be installed. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJWzbGHAAoJEB57S2MheeWy/x8P/RxH4Y4eCzUa8SDnf11XGjcU 4olwcOwxH6mVjhwskAhnIXk4PkQgksjINtBQMsps5sdMblZJ4uDUZw3UyGR3TFYH 2qSKYmgSP9jKRtW8QHJHh6v493wibFtGuR5zpLAjIHsaYaX5T9ZFSll6q/+fHqT9 UrESu0jvpMkFM8oE1FQ3EbVRxacMyIe38ROgBdR3BdEM42PAF+7/NuDfT57YyqJR yjB4ecYO/pdpEo10F9IyEf/tgP9DU/eLPhs7Efr/FDzUVN3ahBPmGBKzbqi0i+os /NnCmUpGngnusteKDnLZ3E3Jaa/0ccM8JPAms0t9l0EnulB6apMpvlhmogLT3Yjy QSkIy7EzW4wswdxX7R50DeTHTWafMD3XuQCvY2cqzObOOIyM8xtRMyThDlzuhUF5 1t3bdb7j3xD1rkHjIC9gwr4TrQYG6QbXnjuyqKqL+IysFrB8IRft3ttytATILHXC /ipE9g6q2fpA58t4c0WT1QY4a9blWLiD35VYl8HOeBTrkC7/9EovKtuEgYIvvvkR tWdl/kaudEP8j6P0pGRN6kbkIiH/O9bhns8j3mCxWvX8aR4kqwM0m8rnNshT5Ijj w8H1SlCrDLEL7aFZIQaG6Eci9AwPsoaHErOaTem9OIXEKkmPXk670DvBsGy08yOB LGTvCvJ0RHXq4a3kcw/T =h8Tj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 2016-02-24 14:35, Jeff Mahoney wrote:
We already have a similar split with -base and we know there are things that may be usable in virtualized environments that we don't include there (other file systems, for example).
The SP1 base kernel is currently at 56MB installed size and counting, to make it usable for JeOS. And right, there is lots of software-only modules like filesystems or network protocols that could in theory be added.
That doesn't mean it hasn't been hugely useful for a lot of people. I can take a preliminary approach to it and post the results. I suppose an obvious question is what to call it? We already have -base, <unqualified>, and -extra for SLES. Do we want to use the -extra name and put everything uncommon in there or try to split it more?
I think having the same package names as in SLE makes sense, even with slightly different semantics.
For the ARM teams, would you be interested in a kernel-default-$board? The same *base* kernel boots, which is the important bit, but then only the modules required for that system would be installed.
I'm afraid that this would end up like the kernel-default-base / kernel-default split in SLE11. I like that we again have a single package that is needed to boot the system. Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (5)
-
Andreas Färber -
Jean Delvare -
Jeff Mahoney -
Matthias Brugger -
Michal Marek