Subject: Re: [RFC PATCH] rtc: add rtc_systohc for ntp use

From: David Brownell <[email-masked]>
Date: Tue, 11 Nov 2008 12:58:59 -0800

On Tuesday 11 November 2008, David Woodhouse wrote:
> I believe you were also concerned that some device wouldn't want the
> behaviour given by the existing sync_cmos_clock() function and workqueue
> stuff in kernel/ntp.c, where we update the clock precisely half-way
> through the second?

That's a problem, yes.  I've never heard of any RTC that wants
such delays ... except for the PC's "CMOS" RTC.

There was some discussion about how to expose that knowledge to
userspace too.  The "hwclock" utility always imposes that delay,
and it shouldn't (except when talking to a PC RTC).

> We should probably rip that code out of ntp.c (or just disable it ifdef
> CONFIG_RTC_CLASS), and provide our own version of notify_cmos_timer().

My suggestion for in-kernel code is that "struct rtc_device" just
grow a field like "unsigned settime_delay_msec" which would never
be initialized except by rtc-cmos (which uses 500) ... and the NTP
sync code would use that value.

For out-of-kernel use, that value could be extracted with an ioctl(),
and used similarly.

> The workqueue stuff to trigger at half-past the second could be kept as
> a library function which most RTC devices would use, but they'd have the
> option to use their own instead.

I thought the workqueue stuff was primarily there to make sure
that RTC was always updated in task context -- so it can grab the
relevant mutex -- and the half-second delay was legacy PC code ...

- Dave