----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/80/#review134 -----------------------------------------------------------
src/arch/alpha/process.cc <http://reviews.m5sim.org/r/80/#comment274> I think that you can safely get rid of checkpointRestored completely, no? From the diff, it looks as if it still lingers. src/sim/sim_object.hh <http://reviews.m5sim.org/r/80/#comment275> Can you please add some comments here explaining exactly what these are for and how they are called? In one of the older e-mails, you wrote up some pseudo code that described the initialization procedure. Perhaps you can put it here as well. - Nathan On 2010-07-29 21:52:33, Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/80/ > ----------------------------------------------------------- > > (Updated 2010-07-29 21:52:33) > > > Review request for Default. > > > Summary > ------- > > sim: revamp unserialization procedure > > Replace direct call to unserialize() on each SimObject with a pair of > calls for better control over initialization in both ckpt and non-ckpt > cases. > > If restoring from a checkpoint, loadState(ckpt) is called on each > SimObject. The default implementation simply calls unserialize() if > there is a corresponding checkpoint section, so we get backward > compatibility for existing objects. However, objects can override > loadState() to get other behaviors, e.g., doing other programmed > initializations after unserialize(), or complaining if no checkpoint > section is found. (Note that the default warning for a missing > checkpoint section is now gone.) > > If not restoring from a checkpoint, we call the new initState() method > on each SimObject instead. This provides a hook for state > initializations that are only required when *not* restoring from a > checkpoint. > > Given this new framework, do some cleanup of LiveProcess subclasses > and X86System, which were (in some cases) emulating initState() > behavior in startup via a local flag or (in other cases) erroneously > doing initializations in startup() that clobbered state loaded earlier > by unserialize(). > > > Diffs > ----- > > src/arch/alpha/process.hh b28e7286990c > src/arch/alpha/process.cc b28e7286990c > src/arch/arm/process.cc b28e7286990c > src/arch/mips/process.hh b28e7286990c > src/arch/mips/process.cc b28e7286990c > src/arch/power/linux/process.hh b28e7286990c > src/arch/power/linux/process.cc b28e7286990c > src/arch/power/process.hh b28e7286990c > src/arch/power/process.cc b28e7286990c > src/arch/sparc/process.hh b28e7286990c > src/arch/sparc/process.cc b28e7286990c > src/arch/x86/linux/system.hh b28e7286990c > src/arch/x86/linux/system.cc b28e7286990c > src/arch/x86/process.hh b28e7286990c > src/arch/x86/process.cc b28e7286990c > src/arch/x86/system.hh b28e7286990c > src/arch/x86/system.cc b28e7286990c > src/python/m5/simulate.py b28e7286990c > src/python/swig/core.i b28e7286990c > src/python/swig/pyobject.hh b28e7286990c > src/python/swig/sim_object.i b28e7286990c > src/sim/process.hh b28e7286990c > src/sim/process.cc b28e7286990c > src/sim/serialize.hh b28e7286990c > src/sim/serialize.cc b28e7286990c > src/sim/sim_object.hh b28e7286990c > src/sim/sim_object.cc b28e7286990c > > Diff: http://reviews.m5sim.org/r/80/diff > > > Testing > ------- > > > Thanks, > > Steve > > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
