Hello everyone,
This message is to serve as an introduction to the RB series 29{29,30,31} that
I just posted to the Review Board, since it may not be obvious what problem it
solves. If you don't use the checkpointing feature or keep your checkpoints
around for very long, then this won't be important to you. But if you've ever
experienced trouble when upgrading checkpoints, it is worth understanding these
changes.
http://reviews.gem5.org/r/2929/
http://reviews.gem5.org/r/2930/
http://reviews.gem5.org/r/2931/
Let's suppose you have developed a change that affects serialization of an
established SimObject, and so you implement a checkpoint upgrader in
util/cpt_upgrader.py. But before you get it committed, someone else commits
another upgrader and takes the version number you were using privately. If
you've already upgraded any checkpoints, then you have to do some annoying
manual workarounds to apply the new upgrade but not your old one and still end
up at the right version number. Other possibilities exist for how you can run
into this problem, but they tend to center around unnecessary contention on the
"official" version number of any checkpoint upgrade.
To solve this problem for ourselves and the greater gem5 community, we propose
replacing the version number scheme with a "version tag" scheme that these
patches implement. Every checkpoint upgrade simply gets a name that we call a
"tag", and both checkpoints and gem5 builds represent their version as an
unordered set of tags. This makes applying patches no more difficult, fixes
the linear numbering problems, and also provides a better user experience if
your checkpoints and gem5 build are mutually incompatible.
Returning to the above example, if your tag was "cache-foo" and someone else
introduced tag "cpu-baz", there would be no conflict. The two potential
conflicts that can happen in this scheme are use of the same tag name and
conflicting checkpoint changes (i.e. modifying the same SimObject in mutually
incompatible ways - but that's a problem outside of checkpoint upgrading
anyway). To make the code merging pain-free, the Python source for the
upgraders are placed in separate files -
util/cpt_upgraders/{cache-foo,cpu-baz}.py in this example.
This change also helps developers and users to maintain private changes that
affect checkpoints or to submit their cpt_upgrader changes upstream in a
different order than they were developed, as those are other scenarios where
the version numbering can cause trouble.
Note: these patches depend on Andreas Sandberg's checkpoint changes.
Thanks,
Curtis
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
