Factoring out common syscalls into asm-generic (was: Re: [uml-devel] Re: [patch 1/7] uml: fix syscall table by including $(SUBARCH)'s one, for i386

[Blaisorblade]

On Thursday 28 April 2005 22:48, Jeff Dike wrote:
> On Thu, Apr 28, 2005 at 11:10:53AM -0700, Chris Wright wrote:
> > * blaisorblade@xxxxxxxx (blaisorblade@xxxxxxxx) wrote:
> > > Split the i386 entry.S files into entry.S and syscall_table.S which
> > > is included in the previous one (so actually there is no difference
> > > between them) and use the syscall_table.S in the UML build, instead of
> > > tracking by hand the syscall table changes (which is inherently
> > > error-prone).
> >
> > Xen can use this as well (it was on my todo list).
>
> Maybe talking out of my ass here, but would it make sense to have the
> generic syscalls in asm-generic, in the form of something like:
> 	SYSCALL(__NR_getpid, sys_getpid)
> ?
>
> The arch include this into its syscall table, would continue to define
> __NR_*, and it would define SYSCALL (but all the syscall tables I've
> seen are just arrays of pointers).  This would allow the arches to
> automatically get all the generic system calls, and they'd continue to
> define on their own any arch-specific things.

The problem is that probably there are little "generic" syscalls. The above 
example is invalid on Alpha, for instance (they have sys_getxpid).

Also, probably, restructuring anything to take advantage of this would be very 
dangerous, error-prone and not rewarding... we (UML) had to do this because 
we had serious maintenance problems, plus the fact that we must *match* other 
syscall tables rather than having our own. Otherwise there's probably no 
reason to rebuild the table.

However, I guess that *new* syscalls are probably often generic, so for them 
there would be a good reason to have some generic idea. Who knows...
-- 
Paolo Giarrusso, aka Blaisorblade
Skype user "PaoloGiarrusso"
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/