Date: Tue, 25 Jul 2006 21:40:34 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, "Christian S.J. Peron" <csjp@FreeBSD.org>, cvs-all@FreeBSD.org, Sam Leffler <sam@errno.com>, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: cvs commit: src/sys/net bpf.c Message-ID: <200607252140.aa88544@salmon.maths.tcd.ie> In-Reply-To: Your message of "Tue, 25 Jul 2006 20:26:54 -0000." <11936.1153859214@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200607252140.aa88544>