RE: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for do_adjtimex()

From: Thomas Shao
Date: Tue Oct 21 2014 - 05:02:54 EST



> -----Original Message-----
> From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Thomas Gleixner
> Sent: Tuesday, October 21, 2014 4:19 PM
> To: Thomas Shao
> Cc: gregkh@xxxxxxxxxxxxxxxxxxx; LKML; devel@xxxxxxxxxxxxxxxxxxxxxx;
> olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx; jasowang@xxxxxxxxxx; KY Srinivasan;
> John Stultz; Richard Cochran
> Subject: RE: [PATCH v2 1/2] timekeeping: add EXPORT_SYMBOL_GPL for
> do_adjtimex()
>
> On Tue, 21 Oct 2014, Thomas Shao wrote:
> > > I still do not have a consistent argument from you WHY you need to
> > > abuse
> > > do_adjtimex() to do that host - guest synchronization in the first place.
> > >
> >
> > I need a function to gradually slew guest time. do_adjtimex() provides
> > all the functionality. Also I could not find any other exposed func to
> > do this. I'd like to hear any feedback from you for this.
>
> As Richard and others told you already, there are various options:
>
> 1) Use NTP on that private network, which does not involve any kernel
> changes at all.
>
> Your argument, that this is hard for IT-Admins to set up is just
> ridiculous. If an IT-Admin is not able to set that up, then he
> should better stay away from setting up a guest in the first place,
> really.
>
> 2) As pointed out already by others PPS/PTP might be a proper solution
> for this.
>
> All it takes is a pair of timestamps (host/guest) injected into the
> proper subsystem and a controlling daemon on the guest side. That
> would also avoid the problem of running NTPd and your kernel side
> poor mans NTPd at the same time.
>
> That pseudo NTP thing is just hilarious, really.
>
> You take the host time stamp in timesync_onchannelcallback() and
> schedule work. From the work queue you correlate the host time
> stamp to the current time of the guest. So you correlate time
> stamps which can be an arbitrary time apart. Brilliant solution
> that, really.
>

OK. I'll investigate these options. Thanks.

> Thanks,
>
> tglx
>
> --
> 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/
--
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/