[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a2W9H7k2S3Bk1323Ro2F=_m48wBy-tENd-MyNe3Z3azyQ@mail.gmail.com>
Date: Wed, 10 Mar 2021 11:00:03 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] powerpc/32: remove bogus ppc_select syscall
On Tue, Mar 9, 2021 at 4:59 PM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
> Le 05/03/2021 à 13:03, Arnd Bergmann a écrit :
> > On Fri, Mar 5, 2021 at 11:15 AM Christophe Leroy
> > <christophe.leroy@...roup.eu> wrote:
> >> Le 05/03/2021 à 11:06, Arnd Bergmann a écrit :
>
> I had another look. In fact x86, arm and m68k still have the #82 syscall, but they don't have the
> hack we have on powerpc to "guess" that something is calling the old select with the arguments of
> the new select.
Makes sense. At least for x86, there are probably still some pre-glibc
binaries around
that would use the old select.
> As part of my series of user accesses cleanup, I'll replace the open coded stuff by a call to
> sys_old_select(), see below.
Nice!
> Maybe at the end we should keep the #82 syscall, but do we need to keep the powerpc hack really ?
> Maybe the best is to drop ppc_select() function but mention sys_old_select() instead of ni_syscall
> for entry #82 in the syscall table ?
I'd say we should either keep the powerpc hack intact (with your cleanup),
or remove the syscall entirely. I have been unable to find any indication of
who might have called the #82 syscall prior to mklinux DR2.1 and linuxppc R4,
so there is no way of knowing which of the two ABIs they were using either.
It was definitely ambiguous since the ancient kernels only had sys_select()
semantics at #82, but the existence of the hack tells us that there were at
least some binaries that wanted the sys_oldselect() semantics.
Arnd
Powered by blists - more mailing lists