On Tue, Jan 24, 2012 at 12:01:10PM +0100, Rudolf Marek wrote:
I'm not sure there would be an issue with third party code (optionroms / old code changing the pit). The seabios timer users are fairly straight forward - get the current value, and then wait for the expected value in a loop with yield(). So, there'd only be a problem if some third-party irq handler messed with the pit - if they did that from a hardware irq handler, I'd guess it would break lots of things. (Things are less clear with CONFIG_THREAD_OPTIONROMS, but I'd say it would be safe to leave that off for your use case.)
Well I had in mind the changes to timer_counter itself. There is an API to change that (1a02) and also there is a rollover. It seems more complex to me to handle all the cases than just use two variables more.
Thinking about this more, I agree with you - it's probably simpler to just keep separate variables.