From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 28 11:45:27 2010 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FC531065670 for ; Sun, 28 Mar 2010 11:45:27 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0928FC12 for ; Sun, 28 Mar 2010 11:45:26 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 0A9AA1FFC51; Sun, 28 Mar 2010 11:45:26 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id D82DD844A7; Sun, 28 Mar 2010 13:45:25 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Peter Jeremy References: <4BACC791.70502@icyb.net.ua> <86zl1v84vy.fsf@ds4.des.no> <4BACD88E.2040803@icyb.net.ua> <86vdcj82qx.fsf@ds4.des.no> <20100326213022.GD32799@server.vk2pj.dyndns.org> <86pr2qlhtf.fsf@ds4.des.no> <20100327214634.GI32799@server.vk2pj.dyndns.org> Date: Sun, 28 Mar 2010 13:45:25 +0200 In-Reply-To: <20100327214634.GI32799@server.vk2pj.dyndns.org> (Peter Jeremy's message of "Sun, 28 Mar 2010 08:46:34 +1100") Message-ID: <86fx3k7jqi.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@FreeBSD.org, Andriy Gapon Subject: Re: periodically save current time to time-of-day hardware X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Mar 2010 11:45:27 -0000 Peter Jeremy writes: > Traditionally, the (PC) RTC is on the ISA bus (though it's possible it > might use I2C on other architectures or LPC on current PCs). AFAIK, it's usually on I2C on non-i386 platforms. I2C RTC chips are dirt cheap and easy to integrate, especially if you already have I2C temperature sensors and whatnot. > > Actually, it might be a good idea to call resettodr() any time the > > clock is stepped. > This should occur now via kern_time.c::settime(). OK. > Given that: > - resettodr() needs to be serialised; > - resettodr() may take a significant amount of time; and > - resettodr() should ideally be synchronised to the second boundary; > maybe creating a kthread to manage the RTC updating is reasonable. If "synchronised to the second boundary" means what I think it means (set the RTC at the exact top-of-the-second), don't go out of your way to implement that. You don't get that kind of accuracy back when you read it anyway - unless it's a calibrated RTC (I've written a Linux driver for one, hence my familiarity with eleven-minute-mode etc.) > A new kthread which sleeps on channel "update_rtc". When woken, it > checks to see if it's within (say) 50msec of a second boundary and so, > it does a trylock on the (new) RTC mutex. If it grabs the mutex then > it performs the update. If it was too far from the second boundary or > it fails to grab the mutex then it sleeps until the next second > boundary and tries again. > > The existing resettodr() would then turn into a wakeup(update_rtc). Sounds good to me, but if only that thread has access to the RTC, why bother with a mutex? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no