>> Did we ever write down what those changes were? I recall that
>> discussion but not the details, and a quick search of my email didn't
>> turn anything up.
>
> No. I think I remember most of the details. I'll try to throw
> together a wiki page.
Ok. Here it is. It's mostly a brain dump wit
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
> Did we ever write down what those changes were? I recall that
> discussion but not the details, and a quick search of my email didn't
> turn anything up.
No. I think I remember most of the details. I'll try to throw
together a wiki page.
Nate
___
On Wed, Aug 4, 2010 at 12:40 PM, nathan binkert wrote:
>
> Perhaps we could figure out if we (or Joel :) could somewhat quickly
> implement some of the Serialization changes that we discussed.
Did we ever write down what those changes were? I recall that
discussion but not the details, and a qui
> 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.
On Wed, Aug 4, 2010 at 8:43 AM, nathan binkert wrote:
>> So should we be converting these subobjects to SimObjects to make it
>> easier to serialize them? Joel previously ran into a bug with the
>> timer object (the MC one) where the Tsunami code was properly
>> calling its serialize/unserial
> So should we be converting these subobjects to SimObjects to make it
> easier to serialize them? Joel previously ran into a bug with the
> timer object (the MC one) where the Tsunami code was properly
> calling its serialize/unserialize functions but the x86 wasn't, which
> would have been a
On Tue, Aug 3, 2010 at 10:43 PM, nathan binkert wrote:
>> No, I don't think those should be SimObjects since they're really just
>> handy abstractions for use internal to the I8042 (PS/2 keyboard and
>> mouse controller). It would be reasonable, though, to still put
>> serialization methods on the
> No, I don't think those should be SimObjects since they're really just
> handy abstractions for use internal to the I8042 (PS/2 keyboard and
> mouse controller). It would be reasonable, though, to still put
> serialization methods on them the I8042 could call so they manage their
> own data. The
No, I don't think those should be SimObjects since they're really just
handy abstractions for use internal to the I8042 (PS/2 keyboard and
mouse controller). It would be reasonable, though, to still put
serialization methods on them the I8042 could call so they manage their
own data. The Channel st
Hi,
This question is probably for Gabe:
I'm currently implementing checkpointing for x86, and I have run into a
question about inheritance with a couple x86-specific devices.
src/dev/x86/i8042.hh defines a PS2Device, which doesn't inherit from
anything, but it looks like the PS2Keyboard and PS
11 matches
Mail list logo
