From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files Date: Fri, 30 Sep 2011 18:55:06 +1000 Message-ID: <20110930085506.GH4512@yookeroo.fritz.box> References: <20110926075144.GT12286@yookeroo.fritz.box> <3D54B89C-A0A3-4461-A7A1-3F1E4AB79296@suse.de> <1317062095.25515.75.camel@bling.home> <4E8111E5.4030209@freescale.com> <4E823FFB.1030508@freescale.com> <1317177625.25515.144.camel@bling.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Alex Williamson , Scott Wood , "kvm@vger.kernel.org" , Stuart Yoder , Benjamin Herrenschmidt , "qemu-devel@nongnu.org" , "avi@redhat.com" To: Alexander Graf Return-path: Received: from e23smtp01.au.ibm.com ([202.81.31.143]:35474 "EHLO e23smtp01.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754590Ab1I3J3m (ORCPT ); Fri, 30 Sep 2011 05:29:42 -0400 Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p8U9S2L8019439 for ; Fri, 30 Sep 2011 19:28:02 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8U9RT9X1798180 for ; Fri, 30 Sep 2011 19:27:29 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8U9TaYG002089 for ; Fri, 30 Sep 2011 19:29:37 +1000 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Sep 28, 2011 at 10:58:26AM +0200, Alexander Graf wrote: > On 28.09.2011, at 04:40, Alex Williamson wrote: > > On Tue, 2011-09-27 at 16:28 -0500, Scott Wood wrote: [snip] > I'm honestly pretty indifferent on ioctl vs. linear read. I got the > impression that people dislike ioctls for whatever reason, so we > went ahead and did the design based on read(). With KVM, ioctls are > a constant pain to extend, but so are the constant sized fields > here. > > Whatever you do, please introduce a "flags" field to every struct > you use and add some padding at the end, so it can possibly be > extended. Yes, those are good ideas. Plus whenever creating an ioctl() that has a structure "return value", it's a good idea for the size of the structure to be specified as an input. Again this allows later extension. Older userspace which only knows the old structure won't get the new fields, but presumably it wouldn't know or care what to do with them anyway. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson