From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44950 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPN9T-0003rw-OF for qemu-devel@nongnu.org; Thu, 17 Jun 2010 18:01:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPN9S-0006Mc-Hz for qemu-devel@nongnu.org; Thu, 17 Jun 2010 18:01:35 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:46059) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPN9S-0006MM-81 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 18:01:34 -0400 From: Paul Brook Date: Thu, 17 Jun 2010 23:01:21 +0100 References: <20100614054923.879.33717.stgit@localhost.localdomain> <1276811010.3216.25.camel@x201> In-Reply-To: <1276811010.3216.25.camel@x201> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006172301.22115.paul@codesourcery.com> Subject: [Qemu-devel] Re: RFC qdev path semantics List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@redhat.com, kvm@vger.kernel.org, Markus Armbruster , qemu-devel@nongnu.org, avi@redhat.com, kraxel@redhat.com > > ### Paul proposes to require all buses to define bus addresses. Make > > one up if necessary. > > That seems arbitrary and prone to breakage. How do we handle a subtle > change in device instantiation order and still allow migration? If by > code change or command line ordering my frobnitz moves from: > > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/0 > > to > > /i440FX-pcihost/pci.0/PIIX3/@01.0/isa.0/1 Two things are apparent here. (a) You've clearly misunderstood the proposals. The paths above make no sense. (b) You've picked a particularly poor definition of device address for the ISA bus. We can do much better than device creation order. > ... > I can live with PATH/@BUS-ADDR if it's still felt that > PATH/IDENT@BUS-ADDR isn't canonical. What that means is that I'll > probably code up vmstate and ramblocks to append IDENT themselves to > keep all the goodness of having per PATH/IDENT namespaces. As discussed elsewhere in this thread, addition of IDENT to the device path is neither necessary nor sufficient for migration. I really feel like we're going round in circles here. Paul