Re: [RFC][PATCH (1/4)] new timeofday core subsystem (v A4)

[john stultz]

On Sat, 2005-04-30 at 09:50 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2005-04-29 at 15:45 -0700, john stultz wrote:
> > All,
> >         This patch implements the architecture independent portion of
> > the time of day subsystem. For a brief description on the rework, see
> > here: http://lwn.net/Articles/120850/ (Many thanks to the LWN team for
> > that clear writeup!)
> > 
> > Mostly this version is just a cleanup of the last release. One neat
> > feature is the new sysfs interface which allows you to manually override
> > the selected timesource while the system is running. 
> > 
> > Included below is timeofday.c (which includes all the time of day
> > management and accessor functions), ntp.c (which includes the ntp
> > scaling calculation code, leapsecond processing, and ntp kernel state
> > machine code), timesource.c (for timesource specific management
> > functions), interface definition .h files, the example jiffies
> > timesource (lowest common denominator time source, mainly for use as
> > example code) and minimal hooks into arch independent code.
> > 
> > The patch does not function without minimal architecture specific hooks
> > (i386, x86-64, ppc32, ppc64, ia64 and s390 examples to follow), and it
> > should be able to be applied to a tree without affecting the code.
> 
> My concern at this point is how to deal with the userland gettimofday
> implementation in the ppc64 vDSO ...

Hopefully in a method very similar to the way the vsyscall patch does
for i386/x86-64. The idea being that the core code makes an arch
specific call passing the core timekeeping values whenever they are
changed. Then the arch specific implementation can use those values in a
similar fashion to calculate time.

I'm not very familiar with ppc64's vDSO implementation, so please let me
know if there is a constraint that would make this difficult.

thanks
-john


-
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/