Re: [PATCH] rm_inter-arch Kconfig dep. (was Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch)
On Sun, May 20, 2007 at 06:01:53PM -0700, Linda Walsh wrote: > Heiko Carstens wrote: > > Send a patch. > > The following seems to work for me. Hope the form is ok. How does > one include source if one wants to compose using Firefox? Seems to > eat the tabs... :-( Are "text/plain" attachments ok to send to the > list? Haven't seen any, but maybe it is not a necessary restrictly? > > Anyway...whatever...here it is... The form is not ok. Please read Documentation/SubmittingPatches "The canonical patch format". Especially a proper description and a Signed-off-by: line is missing. Please resend. > --- > > diff -rNu linux-2.6.21.1/arch/s390/crypto/Kconfig > linux-2.6.21.1-new/arch/s390/crypto/Kconfig > --- linux-2.6.21.1/arch/s390/crypto/Kconfig 2007-04-27 14:49:26.0 > -0700 > +++ linux-2.6.21.1-new/arch/s390/crypto/Kconfig 1969-12-31 > 16:00:00.0 -0800 > @@ -1,60 +0,0 @@ > -config CRYPTO_SHA1_S390 > - tristate "SHA1 digest algorithm" > - depends on S390 > - select CRYPTO_ALGAPI > - help > - This is the s390 hardware accelerated implementation of the > - SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2). > - > -config CRYPTO_SHA256_S390 > - tristate "SHA256 digest algorithm" > - depends on S390 > - select CRYPTO_ALGAPI > - help > - This is the s390 hardware accelerated implementation of the > - SHA256 secure hash standard (DFIPS 180-2). > - > - This version of SHA implements a 256 bit hash with 128 bits of > - security against collision attacks. > - > -config CRYPTO_DES_S390 > - tristate "DES and Triple DES cipher algorithms" > - depends on S390 > - select CRYPTO_ALGAPI > - select CRYPTO_BLKCIPHER > - help > - This us the s390 hardware accelerated implementation of the > - DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3). > - > -config CRYPTO_AES_S390 > - tristate "AES cipher algorithms" > - depends on S390 > - select CRYPTO_ALGAPI > - select CRYPTO_BLKCIPHER > - help > - This is the s390 hardware accelerated implementation of the > - AES cipher algorithms (FIPS-197). AES uses the Rijndael > - algorithm. > - > - Rijndael appears to be consistently a very good performer in > - both hardware and software across a wide range of computing > - environments regardless of its use in feedback or non-feedback > - modes. Its key setup time is excellent, and its key agility is > - good. Rijndael's very low memory requirements make it very well > - suited for restricted-space environments, in which it also > - demonstrates excellent performance. Rijndael's operations are > - among the easiest to defend against power and timing attacks. > - > - On s390 the System z9-109 currently only supports the key size > - of 128 bit. > - > -config S390_PRNG > - tristate "Pseudo random number generator device driver" > - depends on S390 > - default "m" > - help > - Select this option if you want to use the s390 pseudo random number > - generator. The PRNG is part of the cryptograhic processor functions > - and uses triple-DES to generate secure random numbers like the > - ANSI X9.17 standard. The PRNG is usable via the char device > - /dev/prandom. > diff -rNu linux-2.6.21.1/drivers/crypto/Kconfig > linux-2.6.21.1-new/drivers/crypto/Kconfig > --- linux-2.6.21.1/drivers/crypto/Kconfig 2007-04-27 14:49:26.0 > -0700 > +++ linux-2.6.21.1-new/drivers/crypto/Kconfig 2007-05-20 16:41:44.215406026 > -0700 > @@ -51,7 +51,66 @@ > If unsure say M. The compiled module will be > called padlock-sha.ko > > -source "arch/s390/crypto/Kconfig" > +config CRYPTO_SHA1_S390 > + tristate "SHA1 digest algorithm" > + depends on S390 > + select CRYPTO_ALGAPI > + help > + This is the s390 hardware accelerated implementation of the > + SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2). > + > +config CRYPTO_SHA256_S390 > + tristate "SHA256 digest algorithm" > + depends on S390 > + select CRYPTO_ALGAPI > + help > + This is the s390 hardware accelerated implementation of the > + SHA256 secure hash standard (DFIPS 180-2). > + > + This version of SHA implements a 256 bit hash with 128 bits of > + security against collision attacks. > + > +config CRYPTO_DES_S390 > + tristate "DES and Triple DES cipher algorithms" > + depends on S390 > + select CRYPTO_ALGAPI > + select CRYPTO_BLKCIPHER > + help > + This us the s390 hardware accelerated implementation of the > + DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3). > + > +config CRYPTO_AES_S390 > + tristate "AES cipher algorithms" > + depends on S390 > + select CRYPTO_ALGAPI > + select CRYPTO_BLKCIPHER > + help > + This is the s390 hardware accelerated implement
[PATCH] rm_inter-arch Kconfig dep. (was Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch)
Heiko Carstens wrote: > Send a patch. The following seems to work for me. Hope the form is ok. How does one include source if one wants to compose using Firefox? Seems to eat the tabs... :-( Are "text/plain" attachments ok to send to the list? Haven't seen any, but maybe it is not a necessary restrictly? Anyway...whatever...here it is... Linda --- diff -rNu linux-2.6.21.1/arch/s390/crypto/Kconfig linux-2.6.21.1-new/arch/s390/crypto/Kconfig --- linux-2.6.21.1/arch/s390/crypto/Kconfig 2007-04-27 14:49:26.0 -0700 +++ linux-2.6.21.1-new/arch/s390/crypto/Kconfig 1969-12-31 16:00:00.0 -0800 @@ -1,60 +0,0 @@ -config CRYPTO_SHA1_S390 - tristate "SHA1 digest algorithm" - depends on S390 - select CRYPTO_ALGAPI - help - This is the s390 hardware accelerated implementation of the - SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2). - -config CRYPTO_SHA256_S390 - tristate "SHA256 digest algorithm" - depends on S390 - select CRYPTO_ALGAPI - help - This is the s390 hardware accelerated implementation of the - SHA256 secure hash standard (DFIPS 180-2). - - This version of SHA implements a 256 bit hash with 128 bits of - security against collision attacks. - -config CRYPTO_DES_S390 - tristate "DES and Triple DES cipher algorithms" - depends on S390 - select CRYPTO_ALGAPI - select CRYPTO_BLKCIPHER - help - This us the s390 hardware accelerated implementation of the - DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3). - -config CRYPTO_AES_S390 - tristate "AES cipher algorithms" - depends on S390 - select CRYPTO_ALGAPI - select CRYPTO_BLKCIPHER - help - This is the s390 hardware accelerated implementation of the - AES cipher algorithms (FIPS-197). AES uses the Rijndael - algorithm. - - Rijndael appears to be consistently a very good performer in - both hardware and software across a wide range of computing - environments regardless of its use in feedback or non-feedback - modes. Its key setup time is excellent, and its key agility is - good. Rijndael's very low memory requirements make it very well - suited for restricted-space environments, in which it also - demonstrates excellent performance. Rijndael's operations are - among the easiest to defend against power and timing attacks. - - On s390 the System z9-109 currently only supports the key size - of 128 bit. - -config S390_PRNG - tristate "Pseudo random number generator device driver" - depends on S390 - default "m" - help - Select this option if you want to use the s390 pseudo random number - generator. The PRNG is part of the cryptograhic processor functions - and uses triple-DES to generate secure random numbers like the - ANSI X9.17 standard. The PRNG is usable via the char device - /dev/prandom. diff -rNu linux-2.6.21.1/drivers/crypto/Kconfig linux-2.6.21.1-new/drivers/crypto/Kconfig --- linux-2.6.21.1/drivers/crypto/Kconfig 2007-04-27 14:49:26.0 -0700 +++ linux-2.6.21.1-new/drivers/crypto/Kconfig 2007-05-20 16:41:44.215406026 -0700 @@ -51,7 +51,66 @@ If unsure say M. The compiled module will be called padlock-sha.ko -source "arch/s390/crypto/Kconfig" +config CRYPTO_SHA1_S390 + tristate "SHA1 digest algorithm" + depends on S390 + select CRYPTO_ALGAPI + help + This is the s390 hardware accelerated implementation of the + SHA-1 secure hash standard (FIPS 180-1/DFIPS 180-2). + +config CRYPTO_SHA256_S390 + tristate "SHA256 digest algorithm" + depends on S390 + select CRYPTO_ALGAPI + help + This is the s390 hardware accelerated implementation of the + SHA256 secure hash standard (DFIPS 180-2). + + This version of SHA implements a 256 bit hash with 128 bits of + security against collision attacks. + +config CRYPTO_DES_S390 + tristate "DES and Triple DES cipher algorithms" + depends on S390 + select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER + help + This us the s390 hardware accelerated implementation of the + DES cipher algorithm (FIPS 46-2), and Triple DES EDE (FIPS 46-3). + +config CRYPTO_AES_S390 + tristate "AES cipher algorithms" + depends on S390 + select CRYPTO_ALGAPI + select CRYPTO_BLKCIPHER + help + This is the s390 hardware accelerated implementation of the + AES cipher algorithms (FIPS-197). AES uses the Rijndael + algorithm. + + Rijndael appears to be consistently a very good performer in + both hardware and software across a wide range of computing + environments regardless of its use in feedback or non-feedback + m
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
On Fri, May 18, 2007 at 11:47:05PM -0700, Linda Walsh wrote: > Randy Dunlap wrote: > >if S390 > >source "arch/s390/crypto/Kconfig" > >endif > > > Why bother? Why not just move the contents of s390's crypto "Kconfig" > in place of the "source" statement. All the options in s390's Kconfig > are already conditional depending on S390. > > The contents simply need to be [moved] in[to] the the main crypto > config file (./drivers/crypto/Kconfig). > > It "works" fine on i386, don't see why it wouldn't build on any other > arch. Send a patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
Randy Dunlap wrote: if S390 source "arch/s390/crypto/Kconfig" endif Why bother? Why not just move the contents of s390's crypto "Kconfig" in place of the "source" statement. All the options in s390's Kconfig are already conditional depending on S390. The contents simply need to be [moved] in[to] the the main crypto config file (./drivers/crypto/Kconfig). It "works" fine on i386, don't see why it wouldn't build on any other arch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
On Fri, May 18, 2007 at 04:19:20PM -0700, Randy Dunlap wrote: > On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote: > > > Randy Dunlap wrote: > > > On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote: > > > > > > > > >> Seems there is an include of s390 based config in file > > >> drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" > > >> > > >> The line doesn't seem to be need for an i386 build (haven't > > >> tried x86_64 though). > > >> > > >> I take it that this was a braino? > > >> > > > > > > Does it cause a problem? If yes, what problem? > > > > > > > Yes. My source tree has unrelated architectures removed, > > as a result when building i386 or x86_64, the config tools try to > > include files from the s390 architecture. It isn't there. > > I'm building x86, why should I be including files from other > > architectures. It is hierarchically unclean. > > Yes, it is. What removes all arch-except-i386-and-x86_64 from your > kernel tree? Can't it also do > $ sed @source "arch/s390/crypto/Kconfig"@#source "arch/s390/crypto/Kconfig"@ > at the same time? > > Who supports a pared-down kernel tree like this? On op of this I have previously discussed with Roman Zippel the possibility to have _one_ include hirachy for Kconfig files. So that kconfig would fetch all Kconfig files for all archs. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
Robert P. J. Day wrote: On Fri, 18 May 2007, Randy Dunlap wrote: On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote: If the standard that other architectures are using is to put their devices in the crypto directory, then one might expect all crypto devices to be there. Why should s390 stick out and put its crypto device someplace under the s390 tree, forcing parts of the s390 tree to be included when building other architectures? drivers/crypto/ currently contains drivers for x86_32 and s390 (the latter by indirection, which is what is causing you this grief/problem/whatever), but it certainly looks like it could be a home for crypto drivers on any arch. this all sounds vaguely familiar. oh, wait ... http://lkml.org/lkml/2007/3/28/212 I just tried several things to "fix" it, but none of them worked. I wouldn't mind making missing files in *config be non-fatal, i.e., just print a warning message, but I doubt that the maintainer(s) would accept that. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
On Fri, 18 May 2007, Randy Dunlap wrote: > On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote: > > If the standard that other architectures are using is to put their > > devices in the crypto directory, then one might expect all crypto > > devices to be there. Why should s390 stick out and put its crypto > > device someplace under the s390 tree, forcing parts of the s390 > > tree to be included when building other architectures? > > drivers/crypto/ currently contains drivers for x86_32 and s390 (the > latter by indirection, which is what is causing you this > grief/problem/whatever), but it certainly looks like it could be a > home for crypto drivers on any arch. this all sounds vaguely familiar. oh, wait ... http://lkml.org/lkml/2007/3/28/212 rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
On Fri, 18 May 2007 14:46:02 -0700 Linda Walsh wrote: > Randy Dunlap wrote: > > On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote: > > > > > >> Seems there is an include of s390 based config in file > >> drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" > >> > >> The line doesn't seem to be need for an i386 build (haven't > >> tried x86_64 though). > >> > >> I take it that this was a braino? > >> > > > > Does it cause a problem? If yes, what problem? > > > > Yes. My source tree has unrelated architectures removed, > as a result when building i386 or x86_64, the config tools try to > include files from the s390 architecture. It isn't there. > I'm building x86, why should I be including files from other > architectures. It is hierarchically unclean. Yes, it is. What removes all arch-except-i386-and-x86_64 from your kernel tree? Can't it also do $ sed @source "arch/s390/crypto/Kconfig"@#source "arch/s390/crypto/Kconfig"@ at the same time? Who supports a pared-down kernel tree like this? > Perhaps the s390 device needs to be moved under the crypto with > the other crypto devices? Sorry, I didn't quite understand that part. > If the standard that other architectures are > using is to put their devices in the crypto directory, then one might > expect all crypto devices to be there. Why should s390 stick out and > put its crypto device someplace under the s390 tree, forcing parts of the > s390 tree to be included when building other architectures? drivers/crypto/ currently contains drivers for x86_32 and s390 (the latter by indirection, which is what is causing you this grief/problem/whatever), but it certainly looks like it could be a home for crypto drivers on any arch. > > It looks like someone thought that all Hardware crypto devices > > should be listed under the same menu heading. Makes some sense. > > > I thought the idea was the menu reflected the options available in > the specific parts/branches -- i.e. if you have the menu option in > the crypto tree, then the source code should be there as well. I'm not aware of that. E.g., i386 and x86_64 share a lot of code via "#include ../foo/bar" (and it's bad/ugly). > I'm not sure how flexible the include system is, but can't it be > "not included" unless compiling for ARCH_s390? That would be the best solution IMO, if it only worked. :( E.g.: if S390 source "arch/s390/crypto/Kconfig" endif in drivers/crypto/Kconfig. Alas, it doesn't work. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
Randy Dunlap wrote: On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote: Seems there is an include of s390 based config in file drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" The line doesn't seem to be need for an i386 build (haven't tried x86_64 though). I take it that this was a braino? Does it cause a problem? If yes, what problem? Yes. My source tree has unrelated architectures removed, as a result when building i386 or x86_64, the config tools try to include files from the s390 architecture. It isn't there. I'm building x86, why should I be including files from other architectures. It is hierarchically unclean. Perhaps the s390 device needs to be moved under the crypto with the other crypto devices? If the standard that other architectures are using is to put their devices in the crypto directory, then one might expect all crypto devices to be there. Why should s390 stick out and put its crypto device someplace under the s390 tree, forcing parts of the s390 tree to be included when building other architectures? It looks like someone thought that all Hardware crypto devices should be listed under the same menu heading. Makes some sense. I thought the idea was the menu reflected the options available in the specific parts/branches -- i.e. if you have the menu option in the crypto tree, then the source code should be there as well. I'm not sure how flexible the include system is, but can't it be "not included" unless compiling for ARCH_s390? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
On Fri, 18 May 2007 12:32:47 -0700 Linda Walsh wrote: > Seems there is an include of s390 based config in file > drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" > > The line doesn't seem to be need for an i386 build (haven't > tried x86_64 though). > > I take it that this was a braino? Does it cause a problem? If yes, what problem? It looks like someone thought that all Hardware crypto devices should be listed under the same menu heading. Makes some sense. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
Seems there is an include of s390 based config in file drivers/crypto/Kconfig: source "arch/s390/crypto/Kconfig" The line doesn't seem to be need for an i386 build (haven't tried x86_64 though). I take it that this was a braino? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
