Message-ID: <b394bf10-2fc5-6498-955f-a904a756e0c9@landley.net>
Date:   Wed, 8 Feb 2023 21:06:19 -0600
From:   Rob Landley <rob@...dley.net>
To:     Randy Dunlap <rdunlap@...radead.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>
Cc:     Christoph Hellwig <hch@....de>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Kieran Bingham <kieran.bingham+renesas@...asonboard.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        linux-kernel@...r.kernel.org, linux-watchdog@...r.kernel.org,
        devicetree@...r.kernel.org, linux-arch@...r.kernel.org,
        dmaengine@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-renesas-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
        linux-input@...r.kernel.org, linux-media@...r.kernel.org,
        linux-mmc@...r.kernel.org, linux-mtd@...ts.infradead.org,
        netdev@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-rtc@...r.kernel.org, linux-spi@...r.kernel.org,
        linux-serial@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-fbdev@...r.kernel.org, alsa-devel@...a-project.org,
        linux-sh@...r.kernel.org
Subject: Re: remove arch/sh

On 2/3/23 09:57, Randy Dunlap wrote:
> Hi--
> 
> On 2/3/23 02:33, Geert Uytterhoeven wrote:
>> Hi Adrian,
>> 
>> On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz
>> <glaubitz@...sik.fu-berlin.de> wrote:
>>> On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote:
>>>> On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote:
>>>>> Since this is my very first time stepping up as a kernel maintainer, I was hoping
>>>>> to get some pointers on what to do to make this happen.
>>>>>
>>>>> So far, we have set up a new kernel tree and I have set up a local development and
>>>>> test environment for SH kernels using my SH7785LCR board as the target platform.
>>>>>
>>>>> Do I just need to send a patch asking to change the corresponding entry in the
>>>>> MAINTAINERS file?
>>>>
>>>> I'm not sure a there is a document, but:
>>>>
>>>>  - add the MAINTAINERS change to your tree
>>>>  - ask Stephen to get your tree included in linux-next
>>>>
>>>> then eventually send a pull request to Linus with all of that.  Make
>>>> sure it's been in linux-next for a while.
>>>
>>> OK, thanks for the pointers! Will try to get this done by next week.
>>>
>>> We're still discussing among SuperH developer community whether there will be a second
>>> maintainer, so please bear with us a few more days. I will collect patches in the
>>> meantime.
>> 
>> Thanks a lot!
>> 
>> If you need any help with process, setup, ... don't hesitate to ask
>> (on e.g. #renesas-soc on Libera).
> 
> While Adrian and Geert are reading this, I have a question:
> 
> Is this "sh64" still accurate and applicable?

I hadn't noticed it was there... Randy Dunlap added that in 2018 (commit
09b1565324cba). I wonder why?

> from Documentation/kbuild/kbuild.rst:

There isn't an active 64 bit superh architecture for the moment: sh5 was a
prototype that never shipped in volume, and support was removed in commit
37744feebc08. From the j-core side j64 hasn't shipped yet either (still planned
last I heard, but j-core went downmarket first instead due to customer demand,
and multi-issue is on the roadmap before 64 bit address space).

The general trend in linux kernel architectures has been to merge 32 and 64 bit
anyway, and just have the .config set CONFIG_64BIT to distinguish: arch/x86 was
created by merging arch/i386 and arch/x86_64 in 2007, arch/powerpc merged the 32
and 64 bit directories in 2005, arch/s390 and s390x are in the same dir,
arch/mips... (For some reason arm and arm64 are still split, but that might be
fallout from Arm Ltd trying to distinguish aarrcchh6644 from "arm" for some
reason? Dunno.)

I wonder why is this going the other way? I thought $ARCH mostly just specified
the subdirectory under arch/ with a few historical aliases in the top level
Makefile:

# Additional ARCH settings for x86
ifeq ($(ARCH),i386)
        SRCARCH := x86
endif
ifeq ($(ARCH),x86_64)
        SRCARCH := x86
endif

# Additional ARCH settings for sparc
ifeq ($(ARCH),sparc32)
       SRCARCH := sparc
endif
ifeq ($(ARCH),sparc64)
       SRCARCH := sparc
endif

# Additional ARCH settings for parisc
ifeq ($(ARCH),parisc64)
       SRCARCH := parisc
endif

But you could always just specify the correct ARCH directory directly and it
would work. (Always did when I tried it, although I haven't built sparc in years
because there's no musl-libc support, and never built parisc64 because I
couldn't get it to work with uClibc even before musl. I _am_ still building both
32 bit and 64 bit x86 with ARCH=x86 both times...)

> But some architectures such as x86 and sparc have aliases.
> 
> - x86: i386 for 32 bit, x86_64 for 64 bit
> - sh: sh for 32 bit, sh64 for 64 bit <<<<<<<<<<<<<<<
> - sparc: sparc32 for 32 bit, sparc64 for 64 bit

Randy also added the sparc alias in commit 5ba800962a80. That at least exists in
the top level Makefile.

Did he mean parisc64 and typoed sh64? Because that's the only other alias in the
top level Makefile...

In any case, these are historical aliases for old builds, which can probably get
yanked because it should be a trivial fix to use the right ARCH= value for
modern builds? (I'd think?)

You'd even be able to build a 64 bit version of ARCH=i386 just fine if it wasn't
for the ONE place in arch/x86/Kconfig that actually checks:

config 64BIT
        bool "64-bit kernel" if "$(ARCH)" = "x86"
        default "$(ARCH)" != "i386"

Same for arch/sparc/Kconfig:

config 64BIT
        bool "64-bit kernel" if "$(ARCH)" = "sparc"
        default "$(ARCH)" = "sparc64"

Nothing else anywhere seems to care...

> Thanks.

Rob

Powered by blists - more mailing lists