init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
PATCH 1/1 init/Kconfig: make COMPILE_TEST depend on HAS_IOMEM
I read the commit log of the following two:
- bc083a64b6c0 ("init/Kconfig: make COMPILE_TEST depend on !UML")
- 334ef6ed06fa ("init/Kconfig: make COMPILE_TEST depend on !S390")
Both are talking about HAS_IOMEM dependency missing in many drivers.
So, 'depends on HAS_IOMEM' seems the direct, sensible solution to me.
This does not change the behavior of UML. UML still cannot enable COMPILE_TEST because it does not provide HAS_IOMEM.
The current dependency for S390 is too strong. Under the condition of CONFIG_PCI=y, S390 provides HAS_IOMEM, hence can enable COMPILE_TEST.
I also removed the meaningless 'default n'.
---
init/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
init/Kconfig +1 -2
@@ -113,8 +113,7 @@ config INIT_ENV_ARG_LIMIT config COMPILE_TEST bool "Compile also drivers which will not load" - depends on !UML && !S390 - default n + depends on HAS_IOMEM help Some drivers can be compiled on a different platform than they are intended to be run on. Despite they cannot be loaded there (or even
Signature · 1 line
2.27.0
Quoted 8 lines · Masahiro Yamada
I read the commit log of the following two:
-
bc083a64b6c0("init/Kconfig: makeCOMPILE_TESTdepend on !UML")
-334ef6ed06fa("init/Kconfig: makeCOMPILE_TESTdepend on !S390")Both are talking about
HAS_IOMEMdependency missing in many drivers.So, 'depends on
HAS_IOMEM' seems the direct, sensible solution to me.
I don't like idea of hidden indirect dependencies. If a driver needs iomem, then it should depend on it. Yes, a lot of drivers might need to be fixed, but IMHO we should do that, instead of covering 'em up.
--mtx
Signature · 8 lines
--- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering [email protected] -- +49-151-27565287
Quoted 6 lines · metux IT consult
Quoted 5 lines · Masahiro Yamada
I read the commit log of the following two:
-
bc083a64b6c0("init/Kconfig: makeCOMPILE_TESTdepend on !UML")
-334ef6ed06fa("init/Kconfig: makeCOMPILE_TESTdepend on !S390")
Quoted 8 lines
Quoted 3 lines
Both are talking about
HAS_IOMEMdependency missing in many drivers.So, 'depends on
HAS_IOMEM' seems the direct, sensible solution to me.I don't like idea of hidden indirect dependencies. If a driver needs iomem, then it should depend on it. Yes, a lot of drivers might need to be fixed, but IMHO we should do that, instead of covering 'em up.
Unfortunately that does not reflect reality, which was the reason for the above two commits. Problem here is that the cost is not paid by the driver authors, but by architectures which don't support HAS_IOMEM, specifically s390. Driver authors tend to enable COMPILE_TEST but never test on a system with HAS_IOMEM=n (and/or ignore test results provided by build robots).
To a lesser degree, we see the same happen with 32-bit targets. Driver authors often don't compile their drivers in 32-bit mode (just look at 32-bit i386 builds in next-20210224 to see an example). Then it is often up to others to track down and fix the problems. Fortunately, there are still more than a few people who are still interested in 32-bit builds, and problems with those builds tend to get fixed quickly. This is not the case with HAS_IOMEM related issues, where the burden is on very few people.
With that in mind, the dependency introduced with this patch seems to be a workable workaround.
Thanks,
Guenter
Quoted 6 lines · Guenter Roeck
Unfortunately that does not reflect reality, which was the reason for the above two commits. Problem here is that the cost is not paid by the driver authors, but by architectures which don't support
HAS_IOMEM, specifically s390. Driver authors tend to enableCOMPILE_TESTbut never test on a system with HAS_IOMEM=n (and/or ignore test results provided by build robots).
Still, I believe the bug should be fixed at the source.
Maybe these bots do so much traffic that nobody really cares about them. Do they directly address the author and the corresponding maintainer ? (if that ever happens to one of my drivers, please let me know)
Quoted 8 lines
To a lesser degree, we see the same happen with 32-bit targets. Driver authors often don't compile their drivers in 32-bit mode (just look at 32-bit i386 builds in next-20210224 to see an example). Then it is often up to others to track down and fix the problems. Fortunately, there are still more than a few people who are still interested in 32-bit builds, and problems with those builds tend to get fixed quickly. This is not the case with
HAS_IOMEMrelated issues, where the burden is on very few people.
Could we set up a separate build bot for those configurations, with a different from: address and an a special warning text, so maintainers quickly see they *should* pay attention.
IMHO, this is primarily a problem of handling the massive traffic on lkml and sorting out whats relevant for oneself.
--mtx
Signature · 8 lines
--- Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren GPG/PGP-Schlüssel zu. --- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering [email protected] -- +49-151-27565287