[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 May 2021 21:12:36 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Joakim Tjernlund <Joakim.Tjernlund@...inera.com>, "ldv@...linux.org"
<ldv@...linux.org>, "mpe@...erman.id.au" <mpe@...erman.id.au>
Cc: "libc-dev@...ts.llvm.org" <libc-dev@...ts.llvm.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Linux powerpc new system call instruction and ABI
Excerpts from Nicholas Piggin's message of May 19, 2021 6:42 pm:
> Excerpts from Joakim Tjernlund's message of May 19, 2021 6:08 pm:
>> On Wed, 2021-05-19 at 17:55 +1000, Nicholas Piggin wrote:
>>> Excerpts from Joakim Tjernlund's message of May 19, 2021 5:33 pm:
>>> > On Wed, 2021-05-19 at 02:13 +0300, Dmitry V. Levin wrote:
>>> > > Hi,
>>> > >
>>> > > On Thu, Jun 11, 2020 at 06:12:01PM +1000, Nicholas Piggin wrote:
>>> > > [...]
>>> > > > - Error handling: The consensus among kernel, glibc, and musl is to move to
>>> > > > using negative return values in r3 rather than CR0[SO]=1 to indicate error,
>>> > > > which matches most other architectures, and is closer to a function call.
>>> >
>>> > What about syscalls like times(2) which can return -1 without it being an error?
>>>
>>> They do become errors / indistinguishable and have to be dealt with by
>>> libc or userspace. Which does follow what most architectures do (all
>>> except ia64, mips, sparc, and powerpc actually).
>>>
>>> Interesting question though, it should have been noted.
>>>
>>> Thanks,
>>> Nick
>>
>> I always figured the ppc way was superior. It begs the question if not the other archs should
>> change instead?
>
> It is superior in some ways, not enough to be worth being different.
>
> Other archs are unlikely to change because it would be painful for
> not much benefit. New system calls just should be made to not return
> error numbers. If we ever had a big new version of syscall ABI in
> Linux, we can always use another scv vector number for it.
Or... is it possible at syscall entry to peek the address of
the instruction which caused the call and see if that was a
scv instruction? That would be about as reliable as possible
without having that new flag bit.
Thanks,
Nick
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
