| Message ID | 1541583608-26375-2-git-send-email-vladimir.murzin@arm.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Herbert Xu |
| Headers | show |
| Series | Minor improvements over handling dependency on GAS | expand |
On Wed, Nov 07, 2018 at 09:40:05AM +0000, Vladimir Murzin wrote: > There are cases where the whole feature, for instance arm64/lse or > arm/crypto, can depend on assembler. Current practice is to report > buildtime that selected feature is not supported, which can be quite > annoying... Why is it annoying? You still end up with a working kernel. > It'd nicer if we can check assembler first and opt-in feature > visibility in Kconfig. > > Cc: Masahiro Yamada <yamada.masahiro@socionext.com> > Cc: Will Deacon <will.deacon@arm.com> > Cc: Marc Zyngier <marc.zyngier@arm.com> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> > --- > scripts/Kconfig.include | 4 ++++ > 1 file changed, 4 insertions(+) One issue I have with doing the check like this is that if somebody sends you a .config with e.g. ARM64_LSE_ATOMICS=y and you try to build a kernel using that .config and an old toolchain, the option is silently dropped. I think the diagnostic is actually useful in this case. Will
On 07/11/18 14:55, Will Deacon wrote: > On Wed, Nov 07, 2018 at 09:40:05AM +0000, Vladimir Murzin wrote: >> There are cases where the whole feature, for instance arm64/lse or >> arm/crypto, can depend on assembler. Current practice is to report >> buildtime that selected feature is not supported, which can be quite >> annoying... > > Why is it annoying? You still end up with a working kernel. .config doesn't really represent if option was built or not, annoying part is digging build logs (if anyone's saved them at all!) or relevant parts of dmesg (if option throws anything in there and which not always part of reports). > >> It'd nicer if we can check assembler first and opt-in feature >> visibility in Kconfig. >> >> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> >> Cc: Will Deacon <will.deacon@arm.com> >> Cc: Marc Zyngier <marc.zyngier@arm.com> >> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> >> --- >> scripts/Kconfig.include | 4 ++++ >> 1 file changed, 4 insertions(+) > > One issue I have with doing the check like this is that if somebody sends > you a .config with e.g. ARM64_LSE_ATOMICS=y and you try to build a kernel > using that .config and an old toolchain, the option is silently dropped. I see... at least we have some tools like ./scripts/diffconfig > > I think the diagnostic is actually useful in this case. Fully agree on diagnostic side, any suggestions how it can be improved? Cheers Vladimir > > Will >
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include index dad5583..07c145c 100644 --- a/scripts/Kconfig.include +++ b/scripts/Kconfig.include @@ -22,6 +22,10 @@ success = $(if-success,$(1),y,n) # Return y if the compiler supports <flag>, n otherwise cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null) +# $(as-instr,<instr>) +# Return y if the assembler supports <instr>, n otherwise +as-instr = $(success,printf "%b\n" "$(1)" | $(CC) -Werror -c -x assembler -o /dev/null -) + # $(ld-option,<flag>) # Return y if the linker supports <flag>, n otherwise ld-option = $(success,$(LD) -v $(1))
There are cases where the whole feature, for instance arm64/lse or arm/crypto, can depend on assembler. Current practice is to report buildtime that selected feature is not supported, which can be quite annoying... It'd nicer if we can check assembler first and opt-in feature visibility in Kconfig. Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com> --- scripts/Kconfig.include | 4 ++++ 1 file changed, 4 insertions(+)