[RFC PATCH 1/5] powerpc/syscalls: Remove unused offset parameter

[Arnd Bergmann]

On Wed, Jan 16, 2019 at 1:31 AM Michael Ellerman <mpe at ellerman.id.au> wrote:
>
> Arnd Bergmann <arnd at arndb.de> writes:
> > On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman <mpe at ellerman.id.au> wrote:
> >>
> >> We never pass a value for offset, nor do we need to, so remove the
> >> offset logic.
> >>
> >> Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
> >
> > This change and the next three defeat the idea of having a shared script across
> > all architectures.
>
> The scripts are < 100 lines total, so sharing them across arches is
> really not much of a win. Especially if it requires compromising the
> format of the table on some architectures. Shoe horning the SPU
> visibility into the ABI field was a good hack but I really dislike it
> being the permanent state of our syscall table.

IMHO the main advantage is that sharing the scripts guarantees that
the format remains compatible across all architectures, which in turn
allows us to build additional tooling around these files, and make it
less error-prone to do cross-architecture changes.

> > Firoz has already posted patches to move the scripts to scripts/syscalltbl.sh
>
> Those don't work for x86 AFAICS?

I hope we can address that in a follow-up step, integrating all of arm, s390 and
x86, which had the scripts first.

> > and I think it's better to go on with those patches, as they
> > also guarantee that the format of the files remains consistent across all
> > architectures.
>
> Why is that a requirement?
>
> Another possibility is that we have a separate file that stores the SPU
> visibility, that way our syscall.tbl would have the same format as other
> arches, and we could probably share the scripts, but we'd need our own
> script for generating the SPU table.
>
> I'll hack that up and see how it looks.

Ok. See also what x86 has done, they also have some extensions to
their copy of the script.

I still think that keeping the information about the SPU in the same file
is best, otherwise it becomes harder to maintain as changes to the
main table are done, unless we decide that we don't want to leave
the SPU syscalls as explicit opt-in for future additions.

Even as CellBE hardware was being actively marketed, the syscall
interfaces were never overly popular, so it's unlikely that anyone relies
on future syscalls here anway. From the newlib repository, I see only
eight system calls being used in total: getpid, gettid, pread, pwrite,
read, write, readv, and writev.

      Arnd