No newer system calls for SuperH64?

No newer system calls for SuperH64?

[Marcin Juszkiewicz]

I am maintaining system calls table [1] which shows which system call
has which number on all architectures supported by Linux kernel
(including those removed in last years).

1. https://fedora.juszkiewicz.com.pl/syscalls.html

Today I have noticed that SH64 supports system calls up to 393 which is
pwritev2() one. None of later calls is supported in mainline 5.6-rc tree.

Is it an error in kernel headers or it is true? Or maybe it is an error
in my script but it works fine for other architectures.

Note: I do not own nor plan to own SuperH64 hardware. I do not even
remember where it was used. Just noticed weird state of it.

Affected system calls are:

fsconfig
fsmount
fsopen
fspick
io_uring_enter
io_uring_register
io_uring_setup
move_mount
openat2
open_tree
pidfd_getfd
pidfd_open
pidfd_send_signal
pkey_alloc
pkey_free
pkey_mprotect
rseq
statx

Re: No newer system calls for SuperH64?

[Rich Felker]

On Tue, Feb 04, 2020 at 03:13:23PM +0100, Marcin Juszkiewicz wrote:
> I am maintaining system calls table [1] which shows which system call
> has which number on all architectures supported by Linux kernel
> (including those removed in last years).
> 
> 1. https://fedora.juszkiewicz.com.pl/syscalls.html
> 
> Today I have noticed that SH64 supports system calls up to 393 which is
> pwritev2() one. None of later calls is supported in mainline 5.6-rc tree.
> 
> Is it an error in kernel headers or it is true? Or maybe it is an error
> in my script but it works fine for other architectures.
> 
> Note: I do not own nor plan to own SuperH64 hardware. I do not even
> remember where it was used. Just noticed weird state of it.

One reason you don't own it is that it essentially doesn't exist. :-)
GCC dropped SH64 support a few years ago because the arch essentially
never materialized and keeping it around was a lot of cruft. It should
be removed from the kernel too; I just haven't gotten around to
figuring out how to do that.

Rich

Re: No newer system calls for SuperH64?

[Marcin Juszkiewicz]

W dniu 04.02.2020 o 15:23, Rich Felker pisze:
> On Tue, Feb 04, 2020 at 03:13:23PM +0100, Marcin Juszkiewicz wrote:
>> I am maintaining system calls table [1] which shows which system
>> call has which number on all architectures supported by Linux
>> kernel (including those removed in last years).
>> 
>> 1. https://fedora.juszkiewicz.com.pl/syscalls.html
>> 
>> Today I have noticed that SH64 supports system calls up to 393
>> which is pwritev2() one. None of later calls is supported in
>> mainline 5.6-rc tree.
>> 
>> Is it an error in kernel headers or it is true? Or maybe it is an
>> error in my script but it works fine for other architectures.
>> 
>> Note: I do not own nor plan to own SuperH64 hardware. I do not
>> even remember where it was used. Just noticed weird state of it.
> 
> One reason you don't own it is that it essentially doesn't exist.
> :-) GCC dropped SH64 support a few years ago because the arch
> essentially never materialized and keeping it around was a lot of
> cruft. It should be removed from the kernel too; I just haven't
> gotten around to figuring out how to do that.

Thanks!

I moved sh64 to the part where I keep architectures removed from kernel.

Re: No newer system calls for SuperH64?

[Rob Landley]

On 2/4/20 8:23 AM, Rich Felker wrote:
>> Note: I do not own nor plan to own SuperH64 hardware. I do not even
>> remember where it was used. Just noticed weird state of it.
> 
> One reason you don't own it is that it essentially doesn't exist. :-)
> GCC dropped SH64 support a few years ago because the arch essentially
> never materialized and keeping it around was a lot of cruft. It should
> be removed from the kernel too; I just haven't gotten around to
> figuring out how to do that.

To elaborate: sh1-sh4 were developed by Hitachi in 1990's, and it was the best
selling chip line in the world for about 3 years. But after the 1997 asian
economic crisis Hitachi cut funding to its chip business (as in they didn't even
bother to pay for die shrinks to move existing designs to a new fab process at
higher clock speeds), and a few years later they spun their chip business off as
a new company "Renesas" (in partnership with NEC I think).

Renesas inherited the old designs but did _not_ get most of the design engineers
who'd made them, so they hired new guys and had them try to produce a new 64 bit
superh chip (sh5), and in doing so they made the same mistake Intel made with
the Itanium. They bolted a whole second processor on to the side of superh with
a completely different instruction set, instead of the x86-64 approach of making
a mode bit that changes register size with otherwise mostly the same circuitry
implementing mostly the same instructions for 32 bit and 64 bit modes.

The resulting sh5 design was completely uninteresting, nobody who bought the few
prototype systems they made wound up liking it, and Renesas abandoned sh5
instead of going into mass production.

Rob

P.S. The j-core guys have talked about a x86-64 mode bit style approach for
extending their superh clone into "j64". They haven't shipped that yet either,
but it's at least further confirmation that sh5 isn't coming back.