From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36572) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5lEs-0006Fv-FX for qemu-devel@nongnu.org; Mon, 19 Sep 2011 17:18:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5lEr-00018l-JI for qemu-devel@nongnu.org; Mon, 19 Sep 2011 17:18:54 -0400 Received: from tx2ehsobe001.messaging.microsoft.com ([65.55.88.11]:21680 helo=TX2EHSOBE002.bigfish.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5lEr-00018W-De for qemu-devel@nongnu.org; Mon, 19 Sep 2011 17:18:53 -0400 Message-ID: <4E77B0FE.6000800@freescale.com> Date: Mon, 19 Sep 2011 16:15:42 -0500 From: Scott Wood MIME-Version: 1.0 References: <1316445361.4443.29.camel@bling.home> <4E7799DE.2070406@freescale.com> <1316466464.4443.66.camel@bling.home> In-Reply-To: <1316466464.4443.66.camel@bling.home> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] RFC [v2]: vfio / device assignment -- layout of device fd files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: kvm@vger.kernel.org, Stuart Yoder , agraf@suse.de, qemu-devel@nongnu.org, avi@redhat.com On 09/19/2011 04:07 PM, Alex Williamson wrote: > On Mon, 2011-09-19 at 14:37 -0500, Scott Wood wrote: >>> A DTPATH as a record, an INTERRUPT as a sub-record, etc. >> >> Same as any other unrecognized (sub)record type, you ignore it -- but >> the kernel should not be generating this. > > I'm trying to express that I think the spec is unclear here. It's easy > to hand wave that the code will do the right thing, but if the next > person comes along and doesn't understand that a DTPATH is only a > sub-type and a DTINDEX needs to be paired with a DTPATH, then we've > failed. Sure, the spec needs to be clear about which types are expected in each context. >> I'd prefer to keep one numberspace, with documented restrictions on what >> types/subtypes are allowed in each context. Makes it easier if we end >> up in a situation where a (sub)record type is applicable to multiple >> contexts, and easier to detect when an error has been made. > > Couldn't we accomplish the same with separate type and subtype number > spaces? > > enum types { > REGION, > INTERRUPT, > }; > > enum subtypes { > DTPATH, > DTINDEX, > PHYS_ADDR, > PCI_CONFIG_SPACE, > PCI_BAR_INDEX, > }; > > I just find it confusing that we intermix them when defining them. > Thanks, As long as we don't have separate numberspaces for PCI/DT/future-stuff, I'm reasonably happy. -Scott