From: Paul Gortmaker <paul.gortmaker@windriver.com>
To: Markos Chandras <Markos.Chandras@imgtec.com>
Cc: David Daney <ddaney.cavm@gmail.com>,
"linux-mips@linux-mips.org" <linux-mips@linux-mips.org>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>
Subject: Re: [PATCH] samples/seccomp/Makefile: Do not build tests if cross-compiling for MIPS
Date: Tue, 18 Feb 2014 23:21:09 -0500 [thread overview]
Message-ID: <20140219042109.GE5799@windriver.com> (raw)
In-Reply-To: <53020D12.6060000@imgtec.com>
[Re: [PATCH] samples/seccomp/Makefile: Do not build tests if cross-compiling for MIPS] On 17/02/2014 (Mon 13:22) Markos Chandras wrote:
> On 02/14/2014 01:33 AM, Paul Gortmaker wrote:
> >On Thu, Feb 13, 2014 at 1:30 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> >>Really I think we should add a Kconfig item for this and disable the whole
> >>directory for targets that do not support it.
> >
> >Can we do something based on CONFIG_CROSS_COMPILE vs. adding more Kconfig?
> >
> >Paul.
> >--
>
> Hi Paul,
>
> I am not sure how this would solve anything. CONFIG_CROSS_COMPILE
> could be empty, but you can still use 'make
> CROSS_COMPILE=mips-linux-foobar-' or whatever to cross-compile for
> MIPS. So using this symbol to disable tests does not seem right to
> me.
>
> Another Kconfig symbol should be more appropriate but as far as I
> can see MIPS is the only architecture which has this problem (or I
> may have missed all{yes,mod}config failures from other
> architectures).
>
> I still think that an "ifndef CONFIG_MIPS" is good enough for now
> until more architectures suffer from this problem in the future. So
> far (and looking at the git history of that file) other
> architectures managed to workaround this.
I don't have a specific preference to any one fix over another; I leave
that to the seccomp folks who review the fix. But I would like to see
it dealt with ASAP. The regression has been in linux-next for roughly a
week now, and doing that can mask us from seeing other build regressions
silently stacking up behind this one.
Thanks,
Paul.
--
>
> -- markos
>
prev parent reply other threads:[~2014-02-19 4:20 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-13 17:27 [PATCH] samples/seccomp/Makefile: Do not build tests if cross-compiling for MIPS Markos Chandras
2014-02-13 17:27 ` Markos Chandras
2014-02-13 17:30 ` Markos Chandras
2014-02-13 17:30 ` Markos Chandras
2014-02-19 10:15 ` [PATCH v2] " Markos Chandras
2014-02-19 10:15 ` Markos Chandras
2014-03-12 11:22 ` Markos Chandras
2014-03-12 11:22 ` Markos Chandras
2014-02-13 18:30 ` [PATCH] " David Daney
2014-02-14 1:33 ` Paul Gortmaker
2014-02-17 13:22 ` Markos Chandras
2014-02-19 4:21 ` Paul Gortmaker [this message]
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=20140219042109.GE5799@windriver.com \
--to=paul.gortmaker@windriver.com \
--cc=Markos.Chandras@imgtec.com \
--cc=ddaney.cavm@gmail.com \
--cc=linux-mips@linux-mips.org \
--cc=linux-next@vger.kernel.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.