On Mon, 2006-08-28 at 10:28 +0200, Andi Kleen wrote:

On Monday 28 August 2006 10:19, David Miller wrote:

quoted

I see it as duplication because the person who writes the
kernel is the one who ends up writing the libc syscall
bits or explains to the libc person for that arch how
things work.  

And the way to explain it is to write the reference code.

That's a new and interesting thing to add to the list of things
that /usr/include/linux is _not_:

/usr/include/linux is _not_ a place to dump "reference code" in lieu of
documentation on using kernel interfaces.

Besides, the _syscallX implementations in the kernel were generally
unsuitable for use in that way anyway -- I'd be much more inclined to
rely on the libc version. The kernel version would do strange things
like break with PIC code by using an unavailable register (i386),
misalign 64-bit syscall arguments on 32-bit machines (MIPS), etc. 

quoted

And once one libc implmenetation of this 
exists, it can be used as a reference for other libc
variants.

At least on x86-64 various glibc versions had quite buggy
syscall()s, that is why I never trusted it very much.

I assume these were very _early_ glibc in when the port was new? 

quoted

Finally, once it's done, it's done, and that's it.

Except if you still have to deal with old user land.

The limited subset of old userland which elected to use _syscallX()
instead of libc's syscall(), and which can be fixed fairly easily.

-- 
dwmw2