Re: patch #4 (Re: patch #3 (Re: The time has come for a kernel interfacing library layer))

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Wed, May 11, 2005 at 01:03:35PM -0700, Matthew Dillon wrote:
>     I don't think a mixed ABI is really all that desireable.  It should never
>     happen in real life *except* between ls-elf.so.X and the program, and 
>     that is easy enough to take care of by giving ld-elf it's own syscall
>     layer (which it already basically has anyway).  

Just think about Nvidia. It's the only way to avoid major bumps for a lot
of smaller changes and it's been done by the glibc maintainers before.
The positive side is that we can soon link all shared libraries explicitly
against libc too, which helps to detect old libs.

>     It should not happen between e.g. the program and nominal shared
>     libraries such as libc.so.X that are used by the program.  I don't think
>     we could easily support that sort of thing even if we wanted to.

It's not easy, it requires the symbol versioning I still have to write.
It is possible for a lot of situations though.

> :Why can't we use a variadic function like calling convention?
> :In the kernel we end up allocating a structure and reading the arguments in
> :anyway, so the pointer to the first argument could be passed in directly.
> :After returning from the syscall layer, we could do (almost) the same as
> :the current syscall code, just replacing the kerncall with a normal
> :function call.
> :
> :Joerg
> 
>     I don't see what this solves.  The syscall entry points don't care about
>     specific function prototypes as it stands.   The problem here is still
>     how to deal with errno without introducing lots of cycles into the 
>     non-errored path.

Just like we do in the current code. What about this:

__write:
	movl %esp, %eax
	addl $4, %eax
	call __DF_write	; relocated by RTLD
	jb .2f
	ret
. 2:
	PIC_PROLOGUE
	jmp PIC_PLIT(HIDENAME(cerror))

The kernel trap would take the top-of-argument directly from a register
or via the stack, that's a minimal change. Actually, how this is implemented
would be internal between kernel and kernel interface layer.
When we put the libc syscalls into a special section too and use direct
relocations instead of PIC, all the performance difference to the current
code is one function call.

Joerg