[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87inkq9y9r.fsf@concordia.ellerman.id.au>
Date: Wed, 24 May 2017 23:31:44 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: John Stultz <john.stultz@...aro.org>
Cc: lkml <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Miroslav Lichvar <mlichvar@...hat.com>,
Richard Cochran <richardcochran@...il.com>,
Prarit Bhargava <prarit@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>,
Paul Mackerras <paulus@...ba.org>,
Anton Blanchard <anton@...ba.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Tony Luck <tony.luck@...el.com>,
Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD
John Stultz <john.stultz@...aro.org> writes:
...
> So, long ago I talked w/ Paul Mackerras about the ppc vdso code, as
> ppc has some other legacy "userspace time" code that has to be
> maintained as well (I believe there's not code page, just data page
> that userspace pulls directly from). So for that case, we have the
> problem where we can't do this sub-ns accounting, so the hack there is
> rather then rounding-up and adding to ntp_error in the accumulation
> code (which then causes the mult to slow), we're basically doing it
> in the reader, slowing down mult by one. This will cause userspace
> time to have "steps" where after an accumulation time jumps forward a
> bit, but avoids the possibility of a discontinuity where time jumps
> backwards.
>
> But again, I don't want to pretend I'm not an expert on the ppc side.
> This draft patch doesn't even touch the __kernel_clock_gettime()
> implementations, and was trying to preserve the existing ppc logic
> while transitioning the core code. Its likely that a better fix should
> be done deeper in the ppc side (likely splitting the legacy userspace
> data formats out so any hacks only apply to them).
Thanks for all the detail, that's very helpful.
We do export a bunch of values directly to userspace, so we'll have to
come up with some way of making those continue to work, while updating
things enough to unblock the generic code.
Hopefully I can get Paul interested enough to look at it :)
cheers
Powered by blists - more mailing lists