Re: [PATCH] Complain about missing system calls.

Re: [PATCH] Complain about missing system calls.

[Andi Kleen]

David Woodhouse <dwmw2@infradead.org> writes:

> Most system calls seem to get added to i386 first. This patch
> automatically generates a warning for any new system call which is
> implemented on i386 but not the architecture currently being compiled.
> On PowerPC at the moment, for example, it results in these warnings:
> init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
> init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
> init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented

I think a better solution would be to finally switch to auto generated
system call tables for newer system calls. The original reason why the
architectures have different system call numbers -- compatibility with
another "native" Unix -- is completely obsolete now. This leaves only
minor differences of compat stub vs non compat stub and a few
architecture specific calls.

Of course the existing syscall numbers can't be changed, but for all new 
calls one could just add automatically for everybody.

A global table with two entries (compat and non compat) and a per arch 
override table should be sufficient.

Comments?

-Andi

Re: [PATCH] Complain about missing system calls.

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1960 bytes --]

On Fri, 2007-03-09 17:11:10 +0100, Andi Kleen <andi@firstfloor.org> wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
> > Most system calls seem to get added to i386 first. This patch
> > automatically generates a warning for any new system call which is
> > implemented on i386 but not the architecture currently being compiled.
> > On PowerPC at the moment, for example, it results in these warnings:
> > init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
> > init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
> > init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented
> 
> I think a better solution would be to finally switch to auto generated
> system call tables for newer system calls. The original reason why the
> architectures have different system call numbers -- compatibility with
> another "native" Unix -- is completely obsolete now. This leaves only
> minor differences of compat stub vs non compat stub and a few
> architecture specific calls.
> 
> Of course the existing syscall numbers can't be changed, but for all new 
> calls one could just add automatically for everybody.
> 
> A global table with two entries (compat and non compat) and a per arch 
> override table should be sufficient.

Not everybody has a simple indexed list of pointers :)  For example,
for vax-linux, we use a struct per syscall with the expected number of
on-stack longwords for the call.

So if something "new" is coming up, please keep in mind that it should
be flexible enough to represent that. :)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:         "really soon now":      an unspecified period of time, likly to
the second  :                                 be greater than any reasonable definition
                                              of "soon".

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Complain about missing system calls.

[Andi Kleen]

> Not everybody has a simple indexed list of pointers :)  For example,
> for vax-linux, we use a struct per syscall with the expected number of
> on-stack longwords for the call.
> 
> So if something "new" is coming up, please keep in mind that it should
> be flexible enough to represent that. :)

Are there plans to merge vax any time soon to mainline? 

Normally we don't care very much about out of tree code, especially
if it adds complexity like this.

But I suspect s390 would need number of arguments anyways.

-Andi

Re: [PATCH] Complain about missing system calls.

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

On Fri, 2007-03-09 20:00:51 +0100, Andi Kleen <andi@firstfloor.org> wrote:
> > Not everybody has a simple indexed list of pointers :)  For example,
> > for vax-linux, we use a struct per syscall with the expected number of
> > on-stack longwords for the call.
> > 
> > So if something "new" is coming up, please keep in mind that it should
> > be flexible enough to represent that. :)
> 
> Are there plans to merge vax any time soon to mainline? 

Well...  That depends :)  For now, I'd prefer to stay out of mainline,
until we're having gcc-trunk with a current GNU libc up'n'running.
Until then, I plan to at least break the complete ABI once (drop old
syscals and _only_ wire up their modern counterparts.)

> Normally we don't care very much about out of tree code, especially
> if it adds complexity like this.

Sure, but at least mentioning that there's more than only a simple
table of function pointers may or may not help to *plan* the code to
fit future needs.

> But I suspect s390 would need number of arguments anyways.

Any they're already merged. Yay :)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] Complain about missing system calls.

[Martin Schwidefsky]

On Fri, 2007-03-09 at 20:00 +0100, Andi Kleen wrote:
> > Not everybody has a simple indexed list of pointers :)  For example,
> > for vax-linux, we use a struct per syscall with the expected number of
> > on-stack longwords for the call.
> > 
> > So if something "new" is coming up, please keep in mind that it should
> > be flexible enough to represent that. :)
> 
> Are there plans to merge vax any time soon to mainline? 
> 
> Normally we don't care very much about out of tree code, especially
> if it adds complexity like this.
> 
> But I suspect s390 would need number of arguments anyways.

I can't quite follow that line of thought. Why does s390 need the number
of arguments? The wrapper of a compat system call implicitly knows how
many arguments a system calls to do the conversion. For a normal system
call we just call the function. Random example sys_read: the user space
loads the arguments to register %r2, %r3, %r4 and calls the system. The
register are not touched until sys_read is reached. Only sys_read cares
about the number of arguments in this case.

-- 
blue skies,              IBM Deutschland Entwicklung GmbH
   Martin                Vorsitzender des Aufsichtsrats: Johann Weihen
                         Geschäftsführung: Herbert Kircher
Martin Schwidefsky       Sitz der Gesellschaft: Böblingen
Linux on zSeries         Registergericht: Amtsgericht Stuttgart,
   Development           HRB 243294

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] Complain about missing system calls.

[H. Peter Anvin]

Jan-Benedict Glaw wrote:
> 
> Not everybody has a simple indexed list of pointers :)  For example,
> for vax-linux, we use a struct per syscall with the expected number of
> on-stack longwords for the call.
> 
> So if something "new" is coming up, please keep in mind that it should
> be flexible enough to represent that. :)
> 

I discussed with Al Viro a while ago about using something like the 
SYSCALLS.def file from klibc as the source format for the system calls. 
  That would deal very flexibly with almost all kinds of stub generation.

	-hpa

Re: [PATCH] Complain about missing system calls.

[Russell King]

On Fri, Mar 09, 2007 at 11:40:08AM -0800, H. Peter Anvin wrote:
> Jan-Benedict Glaw wrote:
> >
> >Not everybody has a simple indexed list of pointers :)  For example,
> >for vax-linux, we use a struct per syscall with the expected number of
> >on-stack longwords for the call.
> >
> >So if something "new" is coming up, please keep in mind that it should
> >be flexible enough to represent that. :)
> >
> 
> I discussed with Al Viro a while ago about using something like the 
> SYSCALLS.def file from klibc as the source format for the system calls. 
>  That would deal very flexibly with almost all kinds of stub generation.

Hopefully with this idea in place, we can spot new syscalls before
the final release of the kernel (maybe kautobuild can help there)
and fix any silly system call argument ordering which requires
different architectures to have different syscall prototypes (eg,
sys_arm_fadvise64_64 vs sys_fadvise64_64, sys_arm_sync_file_range vs
sys_sync_file_range).

Otherwise the SYSCALLS.def file will probably end up being full of
ifdefs.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH] Complain about missing system calls.

[H. Peter Anvin]

Russell King wrote:
> On Fri, Mar 09, 2007 at 11:40:08AM -0800, H. Peter Anvin wrote:
>> Jan-Benedict Glaw wrote:
>>> Not everybody has a simple indexed list of pointers :)  For example,
>>> for vax-linux, we use a struct per syscall with the expected number of
>>> on-stack longwords for the call.
>>>
>>> So if something "new" is coming up, please keep in mind that it should
>>> be flexible enough to represent that. :)
>>>
>> I discussed with Al Viro a while ago about using something like the 
>> SYSCALLS.def file from klibc as the source format for the system calls. 
>>  That would deal very flexibly with almost all kinds of stub generation.
> 
> Hopefully with this idea in place, we can spot new syscalls before
> the final release of the kernel (maybe kautobuild can help there)
> and fix any silly system call argument ordering which requires
> different architectures to have different syscall prototypes (eg,
> sys_arm_fadvise64_64 vs sys_fadvise64_64, sys_arm_sync_file_range vs
> sys_sync_file_range).

That would definitely be nice.

> Otherwise the SYSCALLS.def file will probably end up being full of
> ifdefs.

... which exactly mirrors the pain and suffering which libc maintainers 
have to deal with.  The amount of time I spent per line of code in klibc 
is quite high, in part because I wanted it to be as self-porting as was 
possible.  I've really tried to avoid arch-specific hacks, and yet there 
are more there than there should be, in large part because of unusable 
or missing kernel header exports.

	-hpa

Re: [PATCH] Complain about missing system calls.

[Benjamin Herrenschmidt]

On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:
> David Woodhouse <dwmw2@infradead.org> writes:
> 
> > Most system calls seem to get added to i386 first. This patch
> > automatically generates a warning for any new system call which is
> > implemented on i386 but not the architecture currently being compiled.
> > On PowerPC at the moment, for example, it results in these warnings:
> > init/missing_syscalls.h:935:3: warning: #warning syscall sync_file_range not implemented
> > init/missing_syscalls.h:947:3: warning: #warning syscall getcpu not implemented
> > init/missing_syscalls.h:950:3: warning: #warning syscall epoll_pwait not implemented
> 
> I think a better solution would be to finally switch to auto generated
> system call tables for newer system calls. The original reason why the
> architectures have different system call numbers -- compatibility with
> another "native" Unix -- is completely obsolete now. This leaves only
> minor differences of compat stub vs non compat stub and a few
> architecture specific calls.
> 
> Of course the existing syscall numbers can't be changed, but for all new 
> calls one could just add automatically for everybody.
> 
> A global table with two entries (compat and non compat) and a per arch 
> override table should be sufficient.

We need additional gunk for syscalls that can be called from SPEs on
cell

Ben.

Re: [PATCH] Complain about missing system calls.

[Andi Kleen]

> We need additional gunk for syscalls that can be called from SPEs on
> cell

Can that gunk not be auto generated?

I know s390 does in some cases, but it looks quite auto generatable to me.

-Andi

>

Re: [PATCH] Complain about missing system calls.

[Martin Schwidefsky]

On Fri, 2007-03-09 at 19:54 +0100, Andi Kleen wrote:
> > We need additional gunk for syscalls that can be called from SPEs on
> > cell
> 
> Can that gunk not be auto generated?
> 
> I know s390 does in some cases, but it looks quite auto generatable to me.

The system call tables and the compat wrapper are all manually created.
If we manage to get the prototypes for the system calls in a parseable
format at least the compat wrappers could be auto-generated. I see two
pitfalls: 1) some compat system calls are directly wired to the system
call table while others need the compat_wrapper detour, 2) override of
system calls with "meta" system calls like sys_socket or sys_ipc.

-- 
blue skies,              IBM Deutschland Entwicklung GmbH
   Martin                Vorsitzender des Aufsichtsrats: Johann Weihen
                         Geschäftsführung: Herbert Kircher
Martin Schwidefsky       Sitz der Gesellschaft: Böblingen
Linux on zSeries         Registergericht: Amtsgericht Stuttgart,
   Development           HRB 243294

"Reality continues to ruin my life." - Calvin.

Re: [PATCH] Complain about missing system calls.

[David Woodhouse]

On Fri, 2007-03-09 at 17:11 +0100, Andi Kleen wrote:
> Of course the existing syscall numbers can't be changed, but for all new 
> calls one could just add automatically for everybody.
> 
> A global table with two entries (compat and non compat) and a per arch 
> override table should be sufficient.

Counterexample: sys_epoll_pwait.

It'd be nice if it were that simple.

It'd also be nice if people stopped thinking it was that simple :)

-- 
dwmw2