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:37:56 +0300 Message-ID: <20130408103756.GB7724@redhat.com> References: <1364856473-25245-1-git-send-email-scottwood@freescale.com> <1364954273-18196-1-git-send-email-scottwood@freescale.com> <1364954273-18196-2-git-send-email-scottwood@freescale.com> <20130404104135.GB17919@redhat.com> <20130405010206.GA22465@drongo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Scott Wood , Alexander Graf , kvm-ppc@vger.kernel.org, kvm@vger.kernel.org To: Paul Mackerras Return-path: Received: from mx1.redhat.com ([209.132.183.28]:61097 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934557Ab3DHKil (ORCPT ); Mon, 8 Apr 2013 06:38:41 -0400 Content-Disposition: inline In-Reply-To: <20130405010206.GA22465@drongo> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Apr 05, 2013 at 12:02:06PM +1100, Paul Mackerras wrote: > On Thu, Apr 04, 2013 at 01:41:35PM +0300, Gleb Natapov wrote: > > > Since now each device has its own fd is it an advantage to enforce > > common interface between different devices? 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. > > I thought about making the same request, but when I looked at it, the > amount of code that could be made common in this way is pretty tiny, > and doing that involves a bit of extra complexity, so I thought that > on the whole it wouldn't be worthwhile. > The value of doing so is not only in making some code common, but also moving fd lifetime management into the common code where it can be debugged once and for all potential users. I also expect the amount of shared code to grow when interface will be used by more architectures. -- Gleb.