[PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Borislav Petkov]

This one should be probably made dependent on some #define saying that the cpu
is an AMD and has the LX Geode crypto hardware built in. Turn it off for now.

Signed-off-by: <petkov@math.uni-muenster.de>


--- current/drivers/crypto/Kconfig.orig	2006-10-21 10:05:08.000000000 +0200
+++ current/drivers/crypto/Kconfig	2006-10-21 10:05:25.000000000 +0200
@@ -56,7 +56,6 @@ config CRYPTO_DEV_GEODE
 	depends on CRYPTO && X86_32
 	select CRYPTO_ALGAPI
 	select CRYPTO_BLKCIPHER
-	default m
 	help
 	  Say 'Y' here to use the AMD Geode LX processor on-board AES
 	  engine for the CryptoAPI AES alogrithm.

		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

Re: [PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Alan Cox]

Ar Sad, 2006-10-21 am 10:17 +0200, ysgrifennodd Borislav Petkov:
> This one should be probably made dependent on some #define saying that the cpu
> is an AMD and has the LX Geode crypto hardware built in. Turn it off for now.

That makes no real sense. Most kernel selections are "run on lots of
processor types", we thus want as much as possible modular, built and
available.

The existing defaults seem quite sane.

Re: [PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Borislav Petkov]

On Mon, Oct 23, 2006 at 12:25:05PM +0100, Alan Cox wrote:
> Ar Sad, 2006-10-21 am 10:17 +0200, ysgrifennodd Borislav Petkov:
> > This one should be probably made dependent on some #define saying that the cpu
> > is an AMD and has the LX Geode crypto hardware built in. Turn it off for now.
> 
> That makes no real sense. Most kernel selections are "run on lots of
> processor types", we thus want as much as possible modular, built and
> available.
> 
> The existing defaults seem quite sane.

... should the duration of the the kernel compilation be prolonged then by 
unneeded modules? Does the majority of people really use that crypto hardware or
is it a small percentage only, we don't know but it also doesn't seem pretty sensible to do
'make oldconfig' and go and turn off all modules that I don't need/have by hand;
it gets quite annoying sometimes too.

-- 
Regards/Gruß,
    Boris.

	

	
		
___________________________________________________________ 
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de

Re: [PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Borislav Petkov]

On Mon, Oct 23, 2006 at 12:25:05PM +0100, Alan Cox wrote:
> Ar Sad, 2006-10-21 am 10:17 +0200, ysgrifennodd Borislav Petkov:
> > This one should be probably made dependent on some #define saying that the cpu
> > is an AMD and has the LX Geode crypto hardware built in. Turn it off for now.
> 
> That makes no real sense. Most kernel selections are "run on lots of
> processor types", we thus want as much as possible modular, built and
> available.
> 
> The existing defaults seem quite sane.


(sorry for the duplicate send but the yahoo mailserver is having problems :()

... should the duration of the the kernel compilation be prolonged then by 
unneeded modules? Does the majority of people really use that crypto hardware or
is it a small percentage only, we don't know but it also doesn't seem pretty sensible to do
'make oldconfig' and go and turn off all modules that I don't need/have by hand;
it gets quite annoying sometimes too.

-- 
Regards/Gruß,
    Boris.

Re: [PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Alan Cox]

Ar Llu, 2006-10-23 am 19:09 +0200, ysgrifennodd Borislav Petkov:
> ... should the duration of the the kernel compilation be prolonged then by 
> unneeded modules? Does the majority of people really use that crypto hardware or
> is it a small percentage only, we don't know but it also doesn't seem pretty sensible to do
> 'make oldconfig' and go and turn off all modules that I don't need/have by hand;
> it gets quite annoying sometimes too.

Every person has a unique and individual definitionof "un-needed
module". In addition developers want more to be compiled as it helps
catch errors earlier. Thus there are reasons for things defaulting to
"on" a lot of the time.

Also bear in mind that you can copy ".config" files between releases and
make oldconfig quite easily so you only have to turn it off once. 

It would be far more productive IMHO to write a tool which generates
a .config file by inspecting the kernel source and the machine upon
which the script is run. This could use the extracted pci data tables in
the modules to produce a correct minimal kernel for many systems.

Alan

Re: [PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Michael Buesch]

On Monday 23 October 2006 13:25, Alan Cox wrote:
> Ar Sad, 2006-10-21 am 10:17 +0200, ysgrifennodd Borislav Petkov:
> > This one should be probably made dependent on some #define saying that the cpu
> > is an AMD and has the LX Geode crypto hardware built in. Turn it off for now.
> 
> That makes no real sense. Most kernel selections are "run on lots of
> processor types", we thus want as much as possible modular, built and
> available.
> 
> The existing defaults seem quite sane.

I can only second that.
Building it as a module does not hurt, except few k disk space.
But that does not really hurt, given today's disk sizes. ;)
And if you have a small disk, you can still disable it.

-- 
Greetings Michael.

Re: [PATCH] do not compile AMD Geode's hwcrypto driver as a module per default

[Borislav Petkov]

On Mon, Oct 23, 2006 at 10:21:14PM +0200, Michael Buesch wrote:
> On Monday 23 October 2006 13:25, Alan Cox wrote:
> > Ar Sad, 2006-10-21 am 10:17 +0200, ysgrifennodd Borislav Petkov:
> > > This one should be probably made dependent on some #define saying that the cpu
> > > is an AMD and has the LX Geode crypto hardware built in. Turn it off for now.
> > 
> > That makes no real sense. Most kernel selections are "run on lots of
> > processor types", we thus want as much as possible modular, built and
> > available.
> > 
> > The existing defaults seem quite sane.
> 
> I can only second that.
> Building it as a module does not hurt, except few k disk space.
> But that does not really hurt, given today's disk sizes. ;)
> And if you have a small disk, you can still disable it.

I get that, but my concern was primarily with the increasing build durations of
the kernel whenever new modules get added in and people want them to be built on
as many systems as possible so as to catch as more bugs as possible. But since
we _want_ that, diskspace is not an issue. 

However, it still does not help that much since I can only test-build the module 
but not test-use it for I don't have the hardware.

-- 
Regards/Gruß,
    Boris.