Hi Everyone, Most of the patches below have received “ship it”s. The exceptions are RB3057 and RB3058 which haven’t received any reviews at all. I’m planning to push the patches on Tuesday next week unless someone asks me to wait.
//Andreas On 19/08/2015 16:02, "Andreas Sandberg" <[email protected]> wrote: >Hi Everyone, > >As I mentioned in an earlier email (Can we kill of AutoSerialize please?), >I have been tempted to kill off support for event auto-serialization. The >main driver behind this has been that it hasn¹t worked since the >introduction of PDES support almost two years ago. Additionally, the >reworked serialization framework that I posted a couple of months ago >accidentally broke this even further (it was confused by a mix of absolute >and relative checkpoint names) and will triggers a panic when gem5 fails >to load auto-serialized events. > >I have finally gotten around to rework the code (mainly EtherLink) that >uses this support. Getting rid of auto-serialization also removed the need >to instantiate things when loading checkpoints, which means we can remove >some fairly complicated code from the serialization framework. > >I¹d appreciate if someone could find time to review the following patches: > >sim: Move SimObject resolver to sim_object.hh [RB3053, 1] >sim: Replace fromInt/fromSimObject with decltype [RB3054, 2] >sim: Remove unused SerializeBuilder interface [RB3055, 3] >sim: Remove autoserialize support for exit events [RB3056, 5] >dev: Remove auto-serialization dependency in EtherLink [RB3057, 4] >sim: Remove broken AutoSerialize support from the event queue [RB3058, 6] > >Since the patches fixes a bug that (sometimes) prevents checkpoints from >multi-system configurations from loading, I¹d like to push the patches >early next week if possible. > >I would also like to point out that checkpoints that have been generated >with ethernet links should load after applying the patches. However, >in-flight packets that were serialized using the auto-serialie feature >won¹t be recreated as doing so would change the behavior of existing >checkpoints. > >//Andreas > >[1] http://reviews.gem5.org/r/3053/ >[2] http://reviews.gem5.org/r/3054/ > >[3] http://reviews.gem5.org/r/3055/ > >[4] http://reviews.gem5.org/r/3056/ > >[5] http://reviews.gem5.org/r/3057/ > >[6] http://reviews.gem5.org/r/3058/ > > > >-- 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 -- 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
