Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

john stultz wrote:

> Please let me know if you have any comments or suggestions. 

I really don't like this special address in the vdso approach.  Yes,
it's unfortunately done for x86-64 as well but this doesn't mean the
mistakes have to be repeated.

Ideally there will be a couple more syscalls which over time can at
least partially be handled at userlevel in the vdso.  Do you want to add
a new special address for each of them?

There are two ways two avoid this which are easy to support in the
current framework:

~ to transparently invoke the optimized syscalls change the DSO entry
code to do a table lookup.  The table content are pointers to code.  By
default, it points to the syscall code we now use.  If there is a
special version of the syscall point to that code and see it magically
called.  No need for libc changes, old libcs automatically take
advantage of the optimizations.  No information about the optimizations
is spilled out to userlevel.

~ alternatively use the symbol table the vdso has.  Export the new code
only via the symbol table.  No fixed address for the function, the
runtime gets it from the symbol table.  glibc will use weak symbol
references; if the symbol isn't there, the old code is used.  This will
require that every single optimized syscall needs to be handled special.


I personally like the first approach better.  The indirection table can
maintained in sync with the syscall table inside the kernel.  It all
comes at all times from the same source.  The overhead of the memory
load should be neglectable.

- -- 
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAGJTa2ijCOnn/RHQRArL2AJ9ULsq2xl3m8TNLNkJydPzrmhQXbACgrlhe
uYIrFlankjw1TIU5W/AdvBA=
=yP4a
-----END PGP SIGNATURE-----
-
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/