linux-kernel - Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}

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: <CAK8P3a0p_5p+OTVR8VxmLrVFJmmwzoXwALv=1NSkk6G6NQMTBg@mail.gmail.com>
Date:   Mon, 29 May 2017 12:50:47 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Olof Johansson <olof@...om.net>, albert@...ive.com
Subject: Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64}

On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt <palmer@...belt.com> wrote:
> On Tue, 23 May 2017 04:30:50 PDT (-0700), Arnd Bergmann wrote:
>> On Tue, May 23, 2017 at 2:41 AM, Palmer Dabbelt <palmer@...belt.com> wrote:
>>> RISC-V has both 32-bit and 64-bit base ISAs, but they are very similar.
>>> Like some other platforms, we'd like to share one arch directory between
>>> the two of them.
>>
>> I think we mainly do the others for backwards-compatibility with ancient
>> build scripts, and we don't need that here. Instead, you could add one more
>> line to the 'SUBARCH:=' statement that interprets the uname output.
>
> I don't think that does the same thing.  The desired effect of this diff is:
>
>  * "uname -m" when running on a RISC-V machine returns either riscv32 or
>    riscv64, as that's what tools like autoconf expect when trying to find
>    tuples.
>
>  * I can cross compile for riscv32 and riscv64.  That's currently controlled by
>    a Kconfig setting, but ARCH=riscv32 vs ARCH=riscv64 controlls what defconfig
>    sets.
>
>  * I can natively compile for riscv32 and riscv64.  That uses the same Kconfig
>    setting, and the same ARCH=riscv32 vs ARCH=riscv64 switch for defconfig.

Right, but my point is that a new architecture should not rely on 'ARCH='
to pick the defconfig, we only do that on a couple of architectures for
backwards compatibility with old scripts.

> Neither of the two Kconfig issues is a big deal, but we de need "uname -m" to
> return "riscv64" or "riscv32" not "riscv".  I think the only way to do that is
> to set SRCARCH, but I'd be happy to change it if there's a better way.  I think
> if I just do this
>
> diff --git a/Makefile b/Makefile
> index 0606f28..4adc609 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -232,7 +232,8 @@ SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
>                                   -e s/arm.*/arm/ -e s/sa110/arm/ \
>                                   -e s/s390x/s390/ -e s/parisc64/parisc/ \
>                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> -                                 -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
> +                                 -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
> +                                 -e s/riscv.*/riscv/ )
>
>  # Cross compiling and selecting different set of gcc/bin-utils
>  # ---------------------------------------------------------------------------
> @@ -269,14 +270,6 @@ ifeq ($(ARCH),x86_64)
>          SRCARCH := x86
>  endif
>
> -# Additional ARCH settings for RISC-V
> -ifeq ($(ARCH),riscv32)
> -       SRCARCH := riscv
> -endif
> -ifeq ($(ARCH),riscv64)
> -       SRCARCH := riscv
> -endif
> -
>  # Additional ARCH settings for sparc
>  ifeq ($(ARCH),sparc32)
>         SRCARCH := sparc
>
> then I'll end up with "uname -m" as "riscv" -- I haven't tried it, but that's
> why we ended up with this diff in the first place.

Do you mean the "uname -m" output comes from "${SRCARCH}" at
the time of the kernel build? That would be easy enough to change
by simply hardcoding it depending on CONFIG_64BIT.

         Arnd