Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Thomas Backlund]

Hi,

Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

I'm trying to package a stripped down version of the kernelsource with 
only arch-specific code (/arch/$arch & /include/asm-$arch), the rest of 
/include, the whole KBuild setup & contents of /scripts to build 
3rdparty drivers against...

With the above files I can do a:
mv .config config.temp
make mrproper
mv config.temp .config
make oldconfig prepare scripts

and the tree stays intact ...

with 2.6.20.4 it works great, but when switching to 2.6.21-rcX it breaks 
with this:

drivers/crypto/Kconfig:55: can't open file "arch/s390/crypto/Kconfig"

I tried to fix drivers/crypto/Kconfig by changing the code to:

if S390
source "arch/s390/crypto/Kconfig"
endif

but it still gets sourced...

Now, since this is the only arch messing up (atleast on ix86 & x86_64),
shouldn't this be fixed somehow ?

--
Thomas

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Jan Glauber]

Hi Thomas,

> with 2.6.20.4 it works great, but when switching to 2.6.21-rcX it breaks 
> with this:
> 
> drivers/crypto/Kconfig:55: can't open file "arch/s390/crypto/Kconfig"

arch/s390/crypto/Kconfig is included there since that is the right place
for the config options to show up.

> I tried to fix drivers/crypto/Kconfig by changing the code to:
> 
> if S390
> source "arch/s390/crypto/Kconfig"
> endif
> 
> but it still gets sourced...

You would need something like:

source "arch/s390/crypto/Kconfig"
	depends on S390

But that is not implemented and I doubt it will since deleting parts of
the kernel tree is not something that is required to work.

Jan

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Robert P. J. Day]

On Fri, 30 Mar 2007, Jan Glauber wrote:

> Hi Thomas,
>
> > with 2.6.20.4 it works great, but when switching to 2.6.21-rcX it breaks
> > with this:
> >
> > drivers/crypto/Kconfig:55: can't open file "arch/s390/crypto/Kconfig"
>
> arch/s390/crypto/Kconfig is included there since that is the right place
> for the config options to show up.
>
> > I tried to fix drivers/crypto/Kconfig by changing the code to:
> >
> > if S390
> > source "arch/s390/crypto/Kconfig"
> > endif
> >
> > but it still gets sourced...
>
> You would need something like:
>
> source "arch/s390/crypto/Kconfig"
> 	depends on S390
>
> But that is not implemented and I doubt it will since deleting parts
> of the kernel tree is not something that is required to work.

  i would think the obvious solution is to move the entire contents of
the s390-specific crypto/Kconfig into the generic one.  obviously,
everything would still work since all of those config options would
still depend on S390.

  i'm betting the S390 folks would *really* hate that idea but, if you
look closely, the generic Kconfig file *already* has some
arch-dependent content:

...
config CRYPTO_DEV_PADLOCK
        tristate "Support for VIA PadLock ACE"
        depends on X86_32     <-----
...

  i think it's a matter of deciding how to be consistent.  either you
allow individual architectures to define their own additional Kconfig
files or you don't.  mixing the two approaches is a recipe for
confusion.

rday


-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Jan Glauber]

On Fri, 2007-03-30 at 05:55 -0400, Robert P. J. Day wrote:
>   i'm betting the S390 folks would *really* hate that idea but, if you
> look closely, the generic Kconfig file *already* has some
> arch-dependent content:
> 
> ...
> config CRYPTO_DEV_PADLOCK
>         tristate "Support for VIA PadLock ACE"
>         depends on X86_32     <-----
> ...

Yes, but the padlock driver is located under drivers/crypto. The s390
crypto stuff is not. It is under arch/s390/crypto, thats why the Kconfig
file is there...

Both solutions (the current and your proposed) are somehow ugly. 
I don't care too much, where the Kconfig entries are, as long as it
works. So if you're interested in changing it go forward and post a
patch...

Jan

>   i think it's a matter of deciding how to be consistent.  either you
> allow individual architectures to define their own additional Kconfig
> files or you don't.  mixing the two approaches is a recipe for
> confusion.
> 
> rday
> 
> 

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Robert P. J. Day]

On Fri, 30 Mar 2007, Jan Glauber wrote:

> On Fri, 2007-03-30 at 05:55 -0400, Robert P. J. Day wrote:
> >   i'm betting the S390 folks would *really* hate that idea but, if you
> > look closely, the generic Kconfig file *already* has some
> > arch-dependent content:
> >
> > ...
> > config CRYPTO_DEV_PADLOCK
> >         tristate "Support for VIA PadLock ACE"
> >         depends on X86_32     <-----
> > ...
>
> Yes, but the padlock driver is located under drivers/crypto. The
> s390 crypto stuff is not. It is under arch/s390/crypto, thats why
> the Kconfig file is there...

  which differs from the way it's handled with x86_64.  even though
the actual crypto routines specific to x86_64 are in
arch/x86_64/crypto (as they are with s390), the menuconfig selections
for them are defined in the *generic* crypto/Kconfig file:

...
config CRYPTO_TWOFISH_X86_64
        tristate "Twofish cipher algorithm (x86_64)"
        depends on (X86 || UML_X86) && 64BIT
        select CRYPTO_ALGAPI
        select CRYPTO_TWOFISH_COMMON
        help
          Twofish cipher algorithm (x86_64).

          Twofish was submitted as an AES (Advanced Encryption Standard)
          candidate cipher by researchers at CounterPane Systems.  It is a
          16 round block cipher supporting key sizes of 128, 192, and 256
          bits.

          See also:
          <http://www.schneier.com/twofish.html>
...


  a little consistency would be nice.  :-)

rday