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

[Michael Ellerman]

Arnd Bergmann <arnd at arndb.de> writes:
> 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.

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

>> > 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.


>> > 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