[PATCH] crypto: x86/camellia - Replace kernel.h with the necessary inclusions

[PATCH] crypto: x86/camellia - Replace kernel.h with the necessary inclusions

[Christophe JAILLET]

When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.

Replace kernel.h inclusion with the list of what is really being used.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
 arch/x86/crypto/camellia.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/crypto/camellia.h b/arch/x86/crypto/camellia.h
index 1dcea79e8f8e..547fb7e30928 100644
--- a/arch/x86/crypto/camellia.h
+++ b/arch/x86/crypto/camellia.h
@@ -4,7 +4,7 @@
 
 #include <crypto/b128ops.h>
 #include <linux/crypto.h>
-#include <linux/kernel.h>
+#include <linux/types.h>
 
 #define CAMELLIA_MIN_KEY_SIZE	16
 #define CAMELLIA_MAX_KEY_SIZE	32
-- 
2.34.1

Re: [PATCH] crypto: x86/camellia - Replace kernel.h with the necessary inclusions

[Herbert Xu]

On Sun, Jun 05, 2022 at 09:32:53AM +0200, Christophe JAILLET wrote:
> When kernel.h is used in the headers it adds a lot into dependency hell,
> especially when there are circular dependencies are involved.
> 
> Replace kernel.h inclusion with the list of what is really being used.
> 
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
>  arch/x86/crypto/camellia.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/crypto/camellia.h b/arch/x86/crypto/camellia.h
> index 1dcea79e8f8e..547fb7e30928 100644
> --- a/arch/x86/crypto/camellia.h
> +++ b/arch/x86/crypto/camellia.h
> @@ -4,7 +4,7 @@
>  
>  #include <crypto/b128ops.h>
>  #include <linux/crypto.h>
> -#include <linux/kernel.h>
> +#include <linux/types.h>
>  
>  #define CAMELLIA_MIN_KEY_SIZE	16
>  #define CAMELLIA_MAX_KEY_SIZE	32

This is not sufficient.  For example, asmlinkage isn't explicitly
defined by any of these header files so it would be relying on an
implicit inclusion which is prone to breakage.

Did you audit the entire file?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: x86/camellia - Replace kernel.h with the necessary inclusions

[Christophe JAILLET]

Le 09/06/2022 à 12:15, Herbert Xu a écrit :
> On Sun, Jun 05, 2022 at 09:32:53AM +0200, Christophe JAILLET wrote:
>> When kernel.h is used in the headers it adds a lot into dependency hell,
>> especially when there are circular dependencies are involved.
>>
>> Replace kernel.h inclusion with the list of what is really being used.
>>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>>   arch/x86/crypto/camellia.h | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/crypto/camellia.h b/arch/x86/crypto/camellia.h
>> index 1dcea79e8f8e..547fb7e30928 100644
>> --- a/arch/x86/crypto/camellia.h
>> +++ b/arch/x86/crypto/camellia.h
>> @@ -4,7 +4,7 @@
>>   
>>   #include <crypto/b128ops.h>
>>   #include <linux/crypto.h>
>> -#include <linux/kernel.h>
>> +#include <linux/types.h>
>>   
>>   #define CAMELLIA_MIN_KEY_SIZE	16
>>   #define CAMELLIA_MAX_KEY_SIZE	32
> 
> This is not sufficient.  For example, asmlinkage isn't explicitly
> defined by any of these header files so it would be relying on an
> implicit inclusion which is prone to breakage.

Agreed, I missed that.

> 
> Did you audit the entire file?

Yes, but I missed the asmlinkage.

In fact, I've sent a few "obvious" (but nothing is never obvious at the 
end...) patches like that to see the interest.

I've spotted a few .h file with "easy to check" content.
Mostly #define, function declarations, a few u<something> datatypes.

Then, I made the #include simplification and compile tested the change.

If it worked, I consider that the patch looks fine.


In this particular case, I guess that the 'asmlinkage' should come from 
another #include when "camellia.h" is used.

My goal was not to introduce some new hidden constraints related to the 
order of the included .h. I just wanted to make them explicit (and 
complete) and start to simplify things.


As said, nothing is never obvious, and I'll stay away from this kind of 
changes :)


Thanks a lot for the review.

CJ



> 
> Cheers,