linux-kernel - Re: [PATCH] [net-next, wrong] make BPFILTER

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]

Message-ID: <20180604235101.fdhkvbx3m7m2u5uc@ast-mbp>
Date:   Mon, 4 Jun 2018 16:51:03 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Masahiro Yamada <yamada.masahiro@...ionext.com>,
        "David S. Miller" <davem@...emloft.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [net-next, wrong] make BPFILTER_UMH depend on X86

On Fri, Jun 01, 2018 at 05:20:12PM +0200, Arnd Bergmann wrote:
> On Thu, May 31, 2018 at 3:42 AM, Masahiro Yamada
> <yamada.masahiro@...ionext.com> wrote:
> > 2018-05-31 0:17 GMT+09:00 Alexei Starovoitov <alexei.starovoitov@...il.com>:
> >> On Mon, May 28, 2018 at 05:31:01PM +0200, Arnd Bergmann wrote:
> 
> > Hmm.
> > For cross-compiling, we set 'ARCH' via the environment variable or the
> > command line.
> >
> > ARCH is not explicitly set, the top-level Makefile sets it to $(SUBARCH)
> >
> >
> > ARCH ?= $(SUBARCH)
> >
> >
> > Maybe, we can assume the native build if $(ARCH) and $(SUBARCH) are the same?
> >
> 
> SUBARCH is also used with a special meaning for arch/um where we build
> with ARCH=um SUBARCH=x86, either on native (x86) or cross builds.
> 
> 
> So doing that would still work in most but not all cases.
> 
> What is the reason for using HOSTCC rather than CC anyway? I think
> the correct way to do this would be to check if CC is able to link binaries
> and disallow the option if it's not.

that's a great idea. Let's do that.

> Don't we already do something like that for tools/testing/selftest which
> also needs to generate binaries with CC?

I couldn't find such makefile magic. Can you please help me with this?