Re: [Qemu-devel] [PATCH 3/8] fdc: Introduce fdctrl->phase

[John Snow <jsnow@redhat.com>]

On 05/20/2015 05:24 AM, Peter Maydell wrote:
> On 20 May 2015 at 09:43, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 20.05.2015 um 10:06 hat Peter Maydell geschrieben:
>>> That handles migration, which is good. But I still think that
>>> storing the same information in two places in the device
>>> state (phase field and the register fields) is error-prone.
>>
>> That's actually my point. The registers are accessed everywhere in the
>> code, whereas phase transitions are in very few well-defined places
>> (there are exactly four of them, iirc). If they get out of sync, chances
>> are that the bug is in the register value, not in the phase. When we
>> know what phase we're in, we can assert the bits and actually catch such
>> bugs.
>>
>>> If we want to switch to having a phase field we should calculate
>>> the relevant register bits on demand based on the phase, rather
>>> than keeping both copies of the state in sync manually.
>>
>> That doesn't work, unfortunately. Some register bits imply a specific
>> phase (assuming correct code), but you can't derive the exact bits just
>> from the phase.
> 
> Having now dug out a copy of the 82078 spec, I agree that the state
> isn't derivable purely from the register values in the general case.
> The controller clearly has a state machine internally but it doesn't
> surface that in the register state except indirectly.
> 
> -- PMM
> 

So even if /currently/ we can reconstitute it from the register values,
we may eventually be unable to.

post_load will work for now, but I fear the case (in ten years) when
someone else cleans up FDC code but fails to realize that the phase is
not explicitly migrated.