On Thu, Aug 20, 2009 at 10:31 AM, Gabriel Michael Black<gbl...@eecs.umich.edu> wrote: > Quoting Steve Reinhardt <ste...@gmail.com>: >> 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).
To paraphrase, I'm right that it would work to replace the code you currently have, but my idea breaks down when you go to implement the update in writeData that's currently left out, correct? I see that now. I guess you can't get rid of the function entirely then, which is too bad. I'm sure I'm overanalyzing this poor little piece of code, but I think the thing that's bothering me is that I can see a couple of reasonable ways to make this work, and what you've got is sort of in the middle. You've split the time into two versions, curTime and clock_data, one of which (curTime) is more easily manipulated in the model and the other (clock_data) which matches what the external device interface needs. Right now your strategy seems to be to keep both of them always in sync (though the update of curTime in writeData() is missing). My inclination is that the code should go all the way in one of two directions: 1. Keep the state simple by only having one copy. Given the need to maintain the *_alrm fields, that would have to be the clock_data version. Then in tickClock() you'd have to convert all the way from that to a time_t back, via a local struct tm, but the rest of the code would be very simple (unchanged from the previous version, I think). 2. Make tickClock() simple by keeping curTime as the offical time as a time_t, then converting to/from clock_data lazily in readData() and writeData(). (This is what I was advocating before.) This is the "high performance" version, since tickClock() probably happens more often than readData() and writeData() (am I wrong to assume that?) but given that tickClock() only happens every simulated second, performance is really irrelevant. So the initial thing that bugged me is that these seem like the main options, and you picked option 1.5 :-). The hope that we could get rid of the TZ mucking-about made changing things even more attractive. Since we can't get rid of the TZ thing, it's less of a big deal, and now that I think about it I prefer option #1 anyway. Do what you will with that... > 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. OK... please add a comment to that effect so we know why that function is there and where it came from. > 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. Wow, that's awesome! > > 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. Hmm, yea... I'll have to take a look at that profile data when I get the chance. Steve _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
