Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]

[ Please strip your replies a bit. I always worry to miss a comment when
scrolling down dozens of pages. ]

On 2011-12-19 23:14, Anthony Liguori wrote:
>> +
>> +struct APICBackend {
>> +    const char *name;
>> +    void (*init)(APICState *s);
>> +    void (*set_base)(APICState *s, uint64_t val);
>> +    void (*set_tpr)(APICState *s, uint8_t val);
>> +    void (*external_nmi)(APICState *s);
>> +
>> +    QSIMPLEQ_ENTRY(APICBackend) entry;
>> +};
> 
> 
> Wouldn't this be more naturally modeled by making APICBackend be a base
> class?
> 
> In qdev today, this would look like:
> 
> struct APICCommon {
>    SysBusDevice qdev;
>    ...
> };
> 
> struct APICCommonInfo {
>     DeviceInfo qdev;
>     void (*init)(APICState *s);
>     void (*set_base)(APICState *s, uint64_t val);
>     void (*set_tpr)(APICState *s, uint8_t val);
>     void (*external_nmi)(APICState *s);
> };
> 
> Take a look at SCSIDevice for an example of this in practice.  This is
> nicer because as we move save/load into devices methods, it becomes
> natural to define the state and save/load function in the base class. 
> Provided it only uses base class state, it lets save/load be compatible
> between both in-kernel and in-qemu device model.

The difference is (unless I completely miss your point) that a common
SCSI base class is used by different derived classes. Here we have a
common frontend class but different base classes, so to say. And we have
a mechanism to chose where to inherit from on instantiation. Precisely
this allows to keep the compatibility between in-kernel and user space
model in this series.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]