Re: [RFC PATCH 1/4] kconfig: add as-instr macro to scripts/Kconfig.include

2018-11-07 Thread Vladimir Murzin
On 07/11/18 14:55, Will Deacon wrote:
> On Wed, Nov 07, 2018 at 09:40:05AM +, 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 
>> Cc: Will Deacon 
>> Cc: Marc Zyngier 
>> Cc: Ard Biesheuvel 
>> Signed-off-by: Vladimir Murzin 
>> ---
>>  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
> 



Re: [RFC PATCH 1/4] kconfig: add as-instr macro to scripts/Kconfig.include

2018-11-07 Thread Will Deacon
On Wed, Nov 07, 2018 at 09:40:05AM +, 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 
> Cc: Will Deacon 
> Cc: Marc Zyngier 
> Cc: Ard Biesheuvel 
> Signed-off-by: Vladimir Murzin 
> ---
>  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


[RFC PATCH 1/4] kconfig: add as-instr macro to scripts/Kconfig.include

2018-11-07 Thread Vladimir Murzin
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 
Cc: Will Deacon 
Cc: Marc Zyngier 
Cc: Ard Biesheuvel 
Signed-off-by: Vladimir Murzin 
---
 scripts/Kconfig.include | 4 
 1 file changed, 4 insertions(+)

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 , n otherwise
 cc-option = $(success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null)
 
+# $(as-instr,)
+# Return y if the assembler supports , n otherwise
+as-instr = $(success,printf "%b\n" "$(1)" | $(CC) -Werror -c -x assembler -o 
/dev/null -)
+
 # $(ld-option,)
 # Return y if the linker supports , n otherwise
 ld-option = $(success,$(LD) -v $(1))
-- 
1.9.1