nathan binkert wrote: >> We do have the Serializable class and could track all the instances of >> that. One question is whether there's enough overhead in SimObjects >> that we really need a lighter-weight class to support these cases. >> > > Well, SimObjects have a Python component and must be described in at > least two files. I think there's a fair amount of extra overhead. > One thing though is that there are certain objects like the > EthPacketData that we wouldn't want to have to get onto and off of the > global serialization list and will still want to serialize manually. > I personally would rather not make things SimObjects that nobody will > ever mess with. Alternatively, we could differentiate a Python > exposed SimObject from a C++ only SimObject. and fold Serializable > into the latter. > > Perhaps we could figure out if we (or Joel :) could somewhat quickly > implement some of the Serialization changes that we discussed. > > Nate > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
In this particular case the mouse/keyboard objects are just stubs to give Linux something to poke at to its satisfaction and don't have any configurability or make sense to plug into anything else. Making them fully fledged SimObjects would be an awkward fit, and overkill since there's a relatively simple alternative. In the case of x86 there really wasn't any previous attempt to serialize, so at least some work was necessary no matter what. I can see how it might not always be clear when objects need to be serialized manually or automatically, though. Gabe _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
