You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't use the serialize feature my self but the following use-case seems broken:
Serialization on machine A
Deserialization on machine B
Structs with a CpuIdReader member will return a mix of machine A and B features.
For example a RdtMonitoringInfo serialized on machine A and deserialized on machine B will return a mix of info. RdtMonitoringInfo::rmid_range() will return machine A info while RdtMonitoringInfo::l3_monitoring() will return machine B info.
The text was updated successfully, but these errors were encountered:
Agreed!
I fear this will likely happen in more places than just RdtMonitoringInfo.
A better solution for serialization/deserialization would probably be to just make CpuId serializeable (by reading all possible/reachable cpuid leafs) and storing/shipping that in a Vec<Vec<CpuIdResult>>. On deserialization a CpuId can be instantiated with with_cpuid_fn or similar function that then just reads from the Vec<Vec<CpuIdResult>>.
I don't use the serialize feature my self but the following use-case seems broken:
Structs with a
CpuIdReader
member will return a mix of machine A and B features.For example a
RdtMonitoringInfo
serialized on machine A and deserialized on machine B will return a mix of info.RdtMonitoringInfo::rmid_range()
will return machine A info whileRdtMonitoringInfo::l3_monitoring()
will return machine B info.The text was updated successfully, but these errors were encountered: