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

Arnd Bergmann [off-list ref] writes:

On Wed, Jan 16, 2019 at 1:31 AM Michael Ellerman [off-list ref] wrote:

quoted

Arnd Bergmann [off-list ref] writes:

quoted

On Mon, Jan 14, 2019 at 12:36 PM Michael Ellerman [off-list ref] wrote:

quoted

We never pass a value for offset, nor do we need to, so remove the
offset logic.

Signed-off-by: Michael Ellerman <mpe@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.

Yeah I guess. Equally those scripts could be made to cope with slight
differences across arches.

quoted

quoted

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.

My worry is that the generic script is going to end up being a big
mish-mash of what's needed by every arch, which makes it harder to
maintain and means we need to coordinate changes across all arches.

quoted

quoted

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.

Yeah I have been looking at theirs. They added a "qualifier" to the
entry, eg. sys_foo/ptregs.

That really should have been an extra column, I'm not sure why they did
it that way, probably to avoid breaking scripts :)

I'd like to do something similar and add a fullregs attribute and use
that to generate stubs that save the full regs for the syscalls that
require it, the same as x86 did.

We could cater to things like that by having a generic "attributes"
column on every arch, and then allow arches to use it for whatever they
need. On powerpc we could use it for spu as well.

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.

I think we do want them opt-in, and I don't anticipate adding any to the
list in future unless someone explicitly asks for them. So I don't
actually think the list will ever change which is why I think it might
work to have it in a separate file.

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.

Right. My policy is all new syscalls are nospu unless someone puts their
hand up to test them.

cheers