From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [RFC PATCH v3 1/6] kvm: add device control API Date: Thu, 4 Apr 2013 18:47:45 -0500 Message-ID: <1365119265.14772.23@snotra> References: <20130404104135.GB17919@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Transfer-Encoding: 8BIT Cc: Alexander Graf , , , To: Gleb Natapov Return-path: In-Reply-To: <20130404104135.GB17919@redhat.com> (from gleb@redhat.com on Thu Apr 4 05:41:35 2013) Content-Disposition: inline Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 04/04/2013 05:41:35 AM, Gleb Natapov wrote: > On Tue, Apr 02, 2013 at 08:57:48PM -0500, Scott Wood wrote: > > +struct kvm_device_attr { > > + __u32 flags; /* no flags currently defined */ > > + __u32 group; /* device-defined */ > > + __u64 attr; /* group-defined */ > > + __u64 addr; /* userspace address of attr data */ > > +}; > > + > Since now each device has its own fd is it an advantage to enforce > common interface between different devices? I think so, even if only to avoid repeating the various pains surrounding adding ioctls. Not necessarily "enforce", just enable. If a device has some sort of command that does not fit neatly into the "set or get" model, it could still add a new ioctl. > If we do so though why not handle file creation, ioctl and file > descriptor lifetime in the > common code. Common code will have "struct kvm_device" with "struct > kvm_device_arch" and "struct kvm_device_ops" members. Instead of > kvm_mpic_ioctl there will be kvm_device_ioctl which will despatch > ioctls > to a device using kvm_device->ops->(set|get|has)_attr pointers. So make it more like the pre-fd version, except for the actual fd usage? It would make destruction a bit simpler (assuming there's no need for vcpu destruction code to access a device). Hopefully nobody asks me to change it back again, though. :-) -Scott