From owner-cvs-all@FreeBSD.ORG Tue Jul 25 20:41:55 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1CE016A513; Tue, 25 Jul 2006 20:41:55 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 0CEB143DE6; Tue, 25 Jul 2006 20:40:34 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 25 Jul 2006 21:40:34 +0100 (BST) To: Poul-Henning Kamp In-reply-to: Your message of "Tue, 25 Jul 2006 20:26:54 -0000." <11936.1153859214@critter.freebsd.dk> Date: Tue, 25 Jul 2006 21:40:34 +0100 From: David Malone Message-ID: <200607252140.aa88544@salmon.maths.tcd.ie> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, "Christian S.J. Peron" , cvs-all@FreeBSD.org, Sam Leffler , Jung-uk Kim Subject: Re: cvs commit: src/sys/net bpf.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2006 20:41:55 -0000 > The first gottcha to look out for is upper/lower half rollover issues, > if you read it as two 32 bit registers: you need to check if the > lower part rolled over without the upper part getting updated, or > the more pathological case: the upper part being updated before > the lower part rolled voer. I'm hoping this will have been done automagically by the HAL layer. > 32 bits is quite likely to be enough for a timecounter so that may > not even be an issue. There is a 32 bit version of the HAL call, and and I believe it is in ms resolution, so, as you say, 32 bits should be fine. > Next is the matter of the crystal that drives it, the temperature > stability of that xtal etc etc. Sam would know better, but I suspect it must be reasonably good because it's needed to keep the 802.11 protocol running smoothly. However, I wanted to have a look and see for myself. > >other things that were available. I'm not sure how much complexity > >a timecounter that could vanish at any moment would introduce - I > >didn't get that far yet. > It's not too bad, we can switch pretty quickly. I guess I was worried about the counter being ejected while a timecounter call was in progress. We'd need some way to indicate that the counter had gone away and the call should be completed using a different timecounter. David.