From: Randy Dunlap <randy.dunlap@oracle.com>
To: Linda Walsh <lkml@tlinx.org>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
Date: Fri, 18 May 2007 16:19:20 -0700 [thread overview]
Message-ID: <20070518161920.ae0ed062.randy.dunlap@oracle.com> (raw)
In-Reply-To: <464E1E9A.8060605@tlinx.org>
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 ***
next prev parent reply other threads:[~2007-05-18 23:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 19:32 building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch Linda Walsh
2007-05-18 21:17 ` Randy Dunlap
2007-05-18 21:46 ` Linda Walsh
2007-05-18 23:19 ` Randy Dunlap [this message]
2007-05-18 23:32 ` Robert P. J. Day
2007-05-19 0:07 ` Randy Dunlap
2007-05-19 5:38 ` Sam Ravnborg
2007-05-19 6:47 ` Linda Walsh
2007-05-20 10:01 ` Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070518161920.ae0ed062.randy.dunlap@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@tlinx.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.