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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 30 Mar 2007 05:55:41 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Jan Glauber <jang@...ux.vnet.ibm.com>
cc:	Thomas Backlund <tmb@...driva.org>, linux-kernel@...r.kernel.org
Subject: Re: Why is arch/s390/crypto/Kconfig sourced when building for another
 arch ?

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/