Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1651683 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} Palmer Dabbelt <palmer@dabbelt.com> - 2017-05-27 03:30 +0200
    Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} Arnd Bergmann <arnd@arndb.de> - 2017-05-29 13:00 +0200
      Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-06 07:00 +0200
        Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} Karsten Merker <merker@debian.org> - 2017-06-06 19:40 +0200
          Re: [PATCH 1/7] RISC-V: Top-Level Makefile for riscv{32,64} Palmer Dabbelt <palmer@dabbelt.com> - 2017-06-06 20:00 +0200

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

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@dabbelt.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.

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.

[toc] | [next] | [standalone]

#1652415

On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt <palmer@dabbelt.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@dabbelt.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

[toc] | [prev] | [next] | [standalone]

#1658352

On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote:
> On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt <palmer@dabbelt.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@dabbelt.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.

OK, I didn't know about COMPAT_UTS_MACHINE.  That's a much better solution,
I'll use that.

[toc] | [prev] | [next] | [standalone]

#1658974

On Mon, Jun 05, 2017 at 09:56:33PM -0700, Palmer Dabbelt wrote:
> On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote:
> > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt <palmer@dabbelt.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@dabbelt.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.
> 
> OK, I didn't know about COMPAT_UTS_MACHINE.  That's a much better solution,
> I'll use that.

Hello Palmer,

I suppose the commit:

  https://github.com/riscv/riscv-linux/commit/8c826930d2a19ecd4f1036f10a380dc4fddd0da5

aims to address this, but it appears to be incomplete. It lacks
the first fragment of the patch above, i.e. the conversion from
the "uname -m" output (i.e. "riscv{64,32}") to the canonical
arch string (i.e. "riscv").  As a result, a native build (which
normally doesn't explicitly pass ARCH=riscv to make and therefore
relies on the output of "uname -m") would fail.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[toc] | [prev] | [next] | [standalone]

#1658997

On Tue, 06 Jun 2017 10:39:04 PDT (-0700), merker@debian.org wrote:
> On Mon, Jun 05, 2017 at 09:56:33PM -0700, Palmer Dabbelt wrote:
>> On Mon, 29 May 2017 03:50:47 PDT (-0700), Arnd Bergmann wrote:
>> > On Sat, May 27, 2017 at 2:57 AM, Palmer Dabbelt <palmer@dabbelt.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@dabbelt.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.
>>
>> OK, I didn't know about COMPAT_UTS_MACHINE.  That's a much better solution,
>> I'll use that.
>
> Hello Palmer,
>
> I suppose the commit:
>
>   https://github.com/riscv/riscv-linux/commit/8c826930d2a19ecd4f1036f10a380dc4fddd0da5
>
> aims to address this, but it appears to be incomplete. It lacks
> the first fragment of the patch above, i.e. the conversion from
> the "uname -m" output (i.e. "riscv{64,32}") to the canonical
> arch string (i.e. "riscv").  As a result, a native build (which
> normally doesn't explicitly pass ARCH=riscv to make and therefore
> relies on the output of "uname -m") would fail.

Sorry about that, I dropped the commit.  I'm in the middle of bisecting to find
a regression, so the patch might now show up for a bit, but it'll be fixed.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web