> Brad's issues with the timer device and checkpointing reminded me that I > wasn't really happy with that code; in particular, the redundant storage in > both clock_data[] and curTime seemed bound to cause problems when they got > out of sync, and in fact Brad's checkpointing fix was incomplete in that it > didn't save and restore curTime. > > I tweaked the code to get rid of curTime; now clock_data is the only state, > and we convert to/from a struct tm only temporarily as needed. This code > passes the regressions, but since there's no X86_FS regression and that > might be the only config that cares, I didn't want to just check it in > without getting some feedback. > > On a separate but related note, I also think that we can get rid of the > mkutctime() call. We really just need a reversible conversion from 'struct > tm' to 'time_t' and back, and although mkutctime/gmtime provides that, I > don't see why mktime/localtime wouldn't do just as well (while being > simpler). Thoughts? I was thinking about that code, more from the perspective that it should go in ClockFields itself. void setTime(time_t time); time_t getTime();
Regarding gmtime, the discussion that came up was related to daylight savings time and that sort of thing. I.e. in theory, incrementing the time by one second could actually make the ClockFields data go backwards. The issue only comes up if someone simulates months of time, but I see no reason to remove the already written code. I guess an alternative could be to use timegm which isn't POSIX, but is present on BSD, Linux, and MacOSX. Windows even has mkgmtime. We could even just steal the correct code from BSD :) Nate _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
