From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [RFC PATCH v3 1/6] kvm: add device control API Date: Mon, 8 Apr 2013 13:34:26 +0300 Message-ID: <20130408103426.GA7724@redhat.com> References: <20130404104135.GB17919@redhat.com> <1365119265.14772.23@snotra> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, paulus@samba.org To: Scott Wood Return-path: Received: from mx1.redhat.com ([209.132.183.28]:10131 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758507Ab3DHKfM (ORCPT ); Mon, 8 Apr 2013 06:35:12 -0400 Content-Disposition: inline In-Reply-To: <1365119265.14772.23@snotra> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Apr 04, 2013 at 06:47:45PM -0500, Scott Wood wrote: > 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. > Make sense. > >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. :-) > -- Gleb.