Re: [patch] new ppc /ppc64 vDSO submission

[Tom Gall <tom_gall at vnet dot ibm dot com>]

On Tue, 6 Dec 2005, Benjamin Herrenschmidt wrote:

> On Sun, 2005-12-04 at 23:24 -0600, Tom Gall wrote:
> > Greetings,
> > 
> > Enclosed is the latest version of the vDSO implementation for ppc/ppc64 
> > for __vdso_get_tbfreq, __vdso_clock_gettime, __vdso_clock_getres and 
> > __vdso_gettimeofday. This patch does it's best to utilize common code so 
> > the copies of clock_gettime.c and clock_getres.c are largely gone in favor 
> > of the common code.
> > 
> > Some small tweaks are possible to the clock_getres.c and clock_gettime.c 
> > code based on some discussions with ben but overall should be in good 
> > shape.
> > 
> > Any and all comments appreciated!
> 
> You are still only replacing the INLINE_SYSCALL code path in clock_gettime.c
> and clock_getres.c and not the INTERNAL_SYSCALL path called from the maybe_*
> functions, thus you don't give a chance to the vDSO to implement any clock
> but MONOTONIC and REALTIME (and only if __ASSUME_POSIX_TIMERS is
> defined, which it hopefully is).

Hi Ben

Yes we talked about this last night. As we agreed to last night when we 
were chatting on irc I was going to look into this and that's what I've 
been doing today, particularily on the kernel end of things.

Given that __ASSUME_POSIX_TIMERS is never defined anywhere it would seem 
there is probably a story behind that, that is crying out to be fully 
understood before I go unwisely rushing off and implementing something 
that I might later regret.
 
> You should also replace the INTENAL_SYSCALL path in the maybe_*
> function, as we discussed earlier. Basically, when the vDSO implement
> clock_gettime() and clock_getres(), _any_ syscall to these should be
> replaced by a vDSO call. The vDSO itself is responsible to decide wether
> to implement a given clock ID itself or internally fallback to the
> syscall, but that should be totally transparent to glibc. That way, if
> figure kernels implement more clocks in the vDSOs, glibc won't have to
> be changed.

Well I wouldn't be so bold as to suggest that glibc might not have to 
change, afterall one never knows as to what's lurking behind the cover of 
some standard yet to be....

Regards,

Tom