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

[KONRAD Frederic]

Le 06/23/2017 à 11:51 AM, Peter Maydell a écrit :
> 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),

Yes I think that makes sense.

> 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.

The point is beeing able to bind/unbind clocks inside the device
to model a clock selector for example. So you just bind/unbind
the input and output clocks.

Secondly you can print the clock input rate in the mtree command
so you can eg: debug it.

Thanks,
Fred

> thanks
> -- PMM