cvs commit: src/sys/net bpf.c

[David Malone]

> 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.