qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v3 00/10] Clock framework API.
Date: Fri, 23 Jun 2017 10:51:29 +0100

On 15 June 2017 at 16:15, Edgar E. Iglesias <address@hidden> wrote:
> On Thu, Jun 15, 2017 at 04:04:56PM +0100, Peter Maydell wrote:
>> The difference here is that the clock objects themselves have
>> internal state. That's not necessarily a bad idea, but it does
>> mean that something's got to migrate that state or otherwise
>> regenerate it. (Anthony once proposed that we should change qemu_irq
>> objects to have internal state, because that's effectively what real
>> hardware is and it would save the need for each device to track its
>> input line state and be notified if the line didn't actually change
>> state. It would just have been an enormous upheaval and migration
>> compat break...)
>
> Thanks. I didn't realize that the internal clock state would be used in a
> way that is not deriveable from other device state & input clocks.
> I'm not sure this is a use-case we need to support, thoughts?
>
> Maybe there's some value in keeping interrupt and clock handling alike,
> e.g removing the internal state from clocks.

It occurs to me that it might be possible to split the
difference, ie the clock object still has internal state,
but the device that owns it is responsible for that state's
migration, so you would have
  VMSTATE_CLOCK(myclock, MyDeviceState),

in the vmstate for every clock you owned. (Not sure whether
that should be "every input clock" or "every output clock"
or even both?)

As an aside, I still find it very odd that you get a clock
object for both an input clock and an output clock. I feel
like we should have one end owns the clock object and the
other just has a reference to it of some kind.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]