Re: Xtensa syscalls (Was: Re: 2.6.12-rc5-mm1)

[Arnd Bergmann <arnd@arndb.de>]

On Middeweken 29 Juni 2005 18:22, Christian Zankel wrote:
> The question is, if we had to break glibc compatibility, shouldn't we 
> use the opportunity to clean-up the syscall list? It was copied from 
> MIPS and, thus, has inherited a lot of legacy from there. As a new 
> architecture, maybe we should even go as far as removing all ni-syscalls 
> and start fresh?

I tried to make the patch in a way that at least the majority of binaries
built against the reduced set of syscalls would still work with old kernels,
though typically not the other way round.

If you don't mind reordering the syscalls, you could even take this
a few steps further:

- remove all 32 bit file syscalls that have a 64 bit replacement
  (e.g. pread, lseek)
- remove all legacy signal handling in favor of rt_sig*
- remove struct stat and rename struct stat64 to stat
- remove wait4 in favor of waitid
- use utimes instead of utime
- use normal calling conventions for sys_pipe
- split sys_xtensa into separate sys_atomic_{set,exg_add,add,cmp_swp}
- if you are still motivated, make this setup the default for an empty
  arch/*/kernel/syscalls.c and no __ARCH_WANT_FOO definitions to make it
  easier to explain to the next architecture port maintainer.

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