LinuxLists.cc - remove arch/sh

2023-01-13 06:36:56

Hi Randy,

On Fri, Feb 3, 2023 at 4:57 PM Randy Dunlap <[email protected]> wrote:
> Is this "sh64" still accurate and applicable? from Documentation/kbuild/kbuild.rst:
>
> 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

No, support for sh64 was removed in commit 37744feebc086908
("sh: remove sh5 support") in v5.8.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

2023-02-05 23:09:12

> Yes, that's the plan. We're collecting the various patches people have sent
> in for arch/sh, review and test them and apply them.
>
> My test board is running the latest kernel now, so I can test new patches, too.

I am just witnessing this development, but I want to say thanks for your
effort and congrats on your progress. Looks like you do the right things
correctly, cool! Kudos also to Geert and others for their assistance.

Attachments:

(No filename) (437.00 B)
signature.asc (833.00 B)
Download all attachments

2023-02-09 02:57:12

by Rob Landley

[permalink] [raw]

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
>> <[email protected]> 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

2023-02-09 03:01:16

by Rob Landley

[permalink] [raw]

Subject: Re: remove arch/sh

On 2/8/23 06:13, John Paul Adrian Glaubitz wrote:
> Hi Randy!
>
> On Tue, 2023-02-07 at 17:31 -0800, Randy Dunlap wrote:
>>
>> On 2/7/23 01:06, John Paul Adrian Glaubitz wrote:
>> > Hello Christoph!
>> >
>> > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote:
>> > > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote:
>> > > > We have had a discussion between multiple people invested in the SuperH port and
>> > > > I have decided to volunteer as a co-maintainer of the port to support Rich Felker
>> > > > when he isn't available.
>> > >
>> > > So, this still isn't reflected in MAINTAINERS in linux-next. When
>> > > do you plan to take over? What platforms will remain supported and
>> > > what can we start dropping due to being unused and unmaintained?
>> >
>> > I'm getting everything ready now with Geert's help and I have a probably dumb
>> > question regarding the MAINTAINERS file change: Shall I just add myself as an
>> > additional maintainer first or shall I also drop Yoshinori Sato?
>> >
>> > Also, is it desirable to add a "T:" entry for the kernel tree?
>>
>> Yes, definitely.
>
> Geert has suggested to wait with adding a tree source to the entry until I get my
> own kernel.org account. I have enough GPG signatures from multiple kernel developers
> on my GPG key, so I think it shouldn't be too difficult to qualify for an account.

So you're not planning to use https://lk.j-core.org/J-Core-Developers/sh-linux
but push to kernel.org and ask Linus to pull from there?

> Adrian

Rob

2023-02-09 09:16:17

by John Paul Adrian Glaubitz

[permalink] [raw]

Subject: Re: remove arch/sh

On Wed, 2023-02-08 at 21:09 -0600, Rob Landley wrote:
> > Geert has suggested to wait with adding a tree source to the entry until I get my
> > own kernel.org account. I have enough GPG signatures from multiple kernel developers
> > on my GPG key, so I think it shouldn't be too difficult to qualify for an account.
>
> So you're not planning to use https://lk.j-core.org/J-Core-Developers/sh-linux
> but push to kernel.org and ask Linus to pull from there?

Yes, that's what Geert recommended.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

2023-02-13 16:31:05

by John Paul Adrian Glaubitz

[permalink] [raw]

Subject: Re: remove arch/sh

Hi Steve!

On Mon, 2023-02-06 at 10:08 +1100, Stephen Rothwell wrote:
> Hi,
>
> On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig <[email protected]> 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
>
> And by "Stephen", Christoph means me. When you are ready, please send
> me a request to include your tree/branch in linux-next (usually the
> branch is called something like "for-next" or just "next") telling me
> the git URL, and the contacts I should send email to if there are
> conflicts/build issues with the branch. I will then fetch the branch
> every time I create a new linux-next release (most work days), so all
> you need to do is update that branch each time you are ready to publish
> more commits.

I'm in the MAINTAINERS now in Linus' tree. I have requested a kernel.org
account now and will hopefully have my trees set up later this week.

I'll let you know about the URLs as soon as possible.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913