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:
  
...


  a little consistency would be nice.  :-)

rday

-
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: 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
> 
> 

-
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: 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

-
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: 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

-
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: 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

-
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: 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

-
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: 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
 
 

-
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: 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

-
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/

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

-
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/

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

-
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/