Re: ppc64 vDSO in mainline

[Roland McGrath <roland at redhat dot com>]

The cache flush entrypoints you are talking about are for the dynamic
linker's own use in relocation, right?  That is actually probably the
easiest thing to do first.  The data structures pointing at the vDSO are
set up fairly early on, before any relocation is done.  So I don't think it
will be hard to do lookups and initialize hooks used by the relocation code.
Put together a patch that works and we'll see how easy it is to integrate;
I think it will be very straightforward.

It's obviously not too hard to make use of the vDSO gettimeofday in some
kludgey way with special code in libc just for that call.  To use vDSO
entry points in the optimal way, i.e. with no intermediate jumps necessary
when the vDSO entry point matches the user ABI, will require some
contemplation about a clean general approach for this in the dynamic
linker.  If you would like to see the dynamic linker point the function
descriptors it sets up directly at your entry points, then we'll have to
work on that plan.

As to providing various information useful to libc such as available
syscalls: I have been playing with some similar stuff (providing the
version information to save the startup uname call).  Using syscall bitmaps
directly will require some hacking to standardize the somewhat haphazard
code arrangements we have now for runtime handling of sometimes-missing
system calls.  (What I've prototyped is cruder, but simply optimizes what
we're already doing rather than needing other code cleaned up.)  The
necessary changes are straightforward and probably a worthwhile cleanup.
But we may not get to them right away.  Moreover, it's very easy to export
all sorts of information from the kernel in this fashion and there is
little platform-specific about doing it, so we should figure out what
information and in what forms are most useful to libc, and then it's not
hard to implement the kernel part uniformly across all the platforms that
have vDSOs.


Thanks,
Roland