linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH v3] powerpc/32: remove bogus ppc_select syscall
Date: Fri, 5 Mar 2021 11:06:09 +0100	[thread overview]
Message-ID: <CAK8P3a2b+u+8smkKWB-V2Non+nnZmNG4dNi6cGpM8weYuY5j6A@mail.gmail.com> (raw)
In-Reply-To: <f08ef2b6f339ba19987cfef4307a4dd26b2faf97.1614933479.git.christophe.leroy@csgroup.eu>

On Fri, Mar 5, 2021 at 9:40 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
> From: Arnd Bergmann <arnd@arndb.de>
>
> The ppc_select function was introduced in linux-2.3.48 in order to support
> code confusing the legacy select() calling convention with the standard one.
> Even 24 years ago, all correctly built code should not have done this and
> could have easily been phased out. Nothing that was compiled later should
> actually try to use the old_select interface, and it would have been broken
> already on all ppc64 kernels with the syscall emulation layer.
>
> This patch brings the 32 bit compat ABI and the native 32 bit ABI for
> powerpc into a consistent state, by removing support for both the
> old_select system call number and the handler for it.

The description still seems wrong, please drop all the nonsense I wrote
back then and explain what is actually going on.

This is what I can see from the linux-history tree:

- The original ppc32 port (linux-1.3.45) had a regular '__NR_select/sys_select'
  syscall at #82 and an unusable '__NR__newselect/sys_panic' syscall at #142,
  while i386 had the indirect '__NR_select/sys_oldselect' syscall at #82
  and the regular '__NR__newselect/sys_select' version at #142. This was
  rather confusing.

- linux-2.1.48 changed both #82 and #142 to the ppc_select() version that
  tries to guess whether the x86 __NR_select/sys_oldselect() behavior or
  the regular __NR__newselect/sys_select() behavior is used.

- linux-2.5.5 added ppc64 support, with a compat version of ppc_select()
  on both #82 and #142 that would either use the __NR__newselect/sys_select
  semantics or panic() when passed an invalud 'n'. The native ppc64
  port started out with just __NR__newselect/sys_select() on #142

- linux-2.5.19 changed ppc64 compat mode to no longer panic(), making
  both #82 and #142 behave like __NR__newselect/sys_select().

- glibc support for ppc32 gets merged during the linux-2.5 days, supporting
  only #142 with the new behavior.

- linux-2.5.41 dropped support for #82 on ppc64 in compat mode but not
  native ppc32.

- linux-2.6.14 merged the two architecture ports but kept the behavior
  unchanged for both.

- linux-2.6.32 changed the native ppc32 #142 __NR__newselect to
  behave the same as compat mode and no longer emulate the
  x86 oldselect, but #82 remained unchanged.

So we have changed behavior multiple times in the past, and the
current state still theoretically allows running non-glibc binaries that
ran on kernels before 2.1.48 that used either the original powerpc
select or the i386 compatible oldselect semantics. Chances are that
those binaries are broken for some other reason now.

          Arnd

  reply	other threads:[~2021-03-05 10:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-05  8:40 [PATCH v3] powerpc/32: remove bogus ppc_select syscall Christophe Leroy
2021-03-05 10:06 ` Arnd Bergmann [this message]
2021-03-05 10:15   ` Christophe Leroy
2021-03-05 12:03     ` Arnd Bergmann
2021-03-09 15:59       ` Christophe Leroy
2021-03-10 10:00         ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a2b+u+8smkKWB-V2Non+nnZmNG4dNi6cGpM8weYuY5j6A@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=benh@kernel.crashing.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).