Quoting Steve Reinhardt <[email protected]>: > Hi Gabe, > > I'm probably missing something here, but all the mucking about with TZ > caught my attention as something that would be nice to avoid. > Wouldn't it work to keep curTime as a time_t and just increment it on > every tick event, then call setTime(*gmtime(&curTime)) only when > you're about to touch clock_data in readData() or writeData()?
I don't think so because after the time gets updated in writeData you need to update the calendar time (time since the epoch). The calendar time needs to be kept up to date for ticking the clock forward, and the broken out time needs to be kept up to date for the registers. To keep them in sync there needs to be a way to go from one to the other in both directions for whichever was updated. Unfortunately POSIX (or whichever standard it is) doesn't include a function to go to calendar time from broken out time in UTC, just from local time. The function I've got is the hack recommended by the nonstandard timegm man page. That said, I wouldn't mind getting rid of it if my reasoning is wrong. > > In fact, you could get rid of the union altogether as a member (but > keep the type) and just create a local instance on each call to > readData() or writeData() that's dynamically populated from the time_t > curTime. (OK, on closer inspection that's not quite so clean since > you do need to store the *_alrm fields separately. So it probably is > easier just to keep the member, but treat all the fields other than > *_alrm as temporaries.) > > I think you're also missing the step of updating curTime if clock_data > is changed in writeData(), independent of whether curTime is a struct > tm or a time_t. Yes I am. I'll add that in when I get a chance. > > BTW, I wanted to congratulate you on all the recent x86 progress,,, > this is looking awesome. I take it you're fixing the RTC because > you're now getting far enough to notice that it's not advancing? Thanks! Yes. Gentoo is booting, the init scripts run, I can log in, cd around, cat some files, and power off/log out. I haven't tried anything more elaborate, but most things seemed to be working ok. One of the init scripts attempts to update the sytem time with the hardware clock using hwclock, and that waits for a second boundary before making any changes. Since the clock didn't increment there was no boundary, and it would spin for a while and give up. It's still timing out, but now only for one of the two invocations. Other than that, messing with the seed for urandom using dd fails, I think because of some unimplemented x87 instructions that show up at that point. Setting up the user font fails as well, I think for the same reason. I need to update the disk image I have on zizzer/etc. so you can try it yourself. It takes around an hour and a half to get to the log in (root/root) which was why I ran m5.prof. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
