qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 09/15] hw: Added generic FIFO API.


From: Peter Crosthwaite
Subject: Re: [Qemu-devel] [PATCH v5 09/15] hw: Added generic FIFO API.
Date: Tue, 7 Aug 2012 16:42:33 +1000

On Tue, Aug 7, 2012 at 4:28 PM, Igor Mitsyanko <address@hidden> wrote:
> On 08/07/2012 10:10 AM, Peter Crosthwaite wrote:
>>>>
>>>> +
>>>> +extern const VMStateDescription vmstate_fifo8;
>>>> +
>>>> +#define VMSTATE_FIFO8(_field, _state) {                              \
>>>> +    .name       = (stringify(_field)),                               \
>>>> +    .size       = sizeof(Fifo8),                                     \
>>>> +    .vmsd       = &vmstate_fifo8,                                    \
>>>> +    .flags      = VMS_STRUCT,                                        \
>>>> +    .offset     = vmstate_offset_value(_state, _field, Fifo8),       \
>>>> +}
>>>
>>>
>>> how about implementing this as a wrapper to VMSTATE_STRUCT_TEST() macro
>>> instead?
>>
>> This has no existing precedent in QEMU so I am unsure of what you mean?
>
>
> I meant VMSTATE_TIMER_TEST() in vmstate.h as an example, which is a wrapper
> to VMSTATE_POINTER_TEST(). With this approach, fifo macro could be
>
> #define VMSTATE_FIFO8(_field, _state) \
> VMSTATE_STRUCT(_field, _state, 0, vmstate_fifo8, Fifo8)
>

Yeh just greppin around it looks like this is functionally equivalent.
VMSTATE_IDE_BUS looks like a reasonable precedent for that. Any
opinions one way or the other RE with my original approach (based on
I2C) vs Igors shortened version?

Regards,
Peter

>
>
>>
>> And maybe this should go to vmstate.h header
>>
>> I disagree. All other clients of VMS_STRUCT are out in their repective
>> device specific headers (pci.h, i2c.h) etc. Unless this is new
>> established policy, I dont really want to change the current adopted
>> approach.
>
>
> Yeah, looks like you're right.
>
>
>> Regards,
>> Peter
>>
>>>
>>>> +
>>>> +#endif /* FIFO_H */
>>>
>>>
>



reply via email to

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