[ 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:
signature.asc
Description: OpenPGP digital signature
