---
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
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
