[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infra

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v5 06/16] apic: Introduce backend/frontend infrastructure for KVM reuse
Date: Tue, 20 Dec 2011 01:32:06 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

On 2011-12-20 01:28, Anthony Liguori wrote:
> On 12/19/2011 05:32 PM, Jan Kiszka wrote:
>>> 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.
> The 'frontend' is the common code and the 'backend' are the bits that
> are different, no?
> We ultimately want there to be two devices that share all of the
> 'frontend' code by providing different 'backend' implementations.
> So make the 'frontend' a base class that provides a set of abstract
> virtual methods (the set you have as the 'backend' interface).  Each
> device instance then inherits from the base class and provides its own
> implementation of the virtual methods.
>> 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.
> Okay, so I really think this is the problem.  The in-kernel APIC is a
> separate device, no a property of the userspace APIC device.
> It should be modeled as two separate devices.

That was v1 of my patches. Avi didn't like it, I tried it like this, and
in the end I had to agree. So, no, I don't think we want such a model.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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