From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43013 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMS1s-0003cu-RE for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:37:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMS1r-0007SW-Ku for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:37:40 -0400 Received: from mail.codesourcery.com ([38.113.113.100]:46590) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMS1r-0007SL-By for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:37:39 -0400 From: Paul Brook Subject: Re: [Qemu-devel] [RFC PATCH 3/6] RAMBlock: Add a name field Date: Wed, 9 Jun 2010 21:36:36 +0100 References: <20100608191447.4451.47795.stgit@localhost.localdomain> <201006091318.49556.paul@codesourcery.com> <1276101449.3079.74.camel@x201> In-Reply-To: <1276101449.3079.74.camel@x201> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201006092136.38569.paul@codesourcery.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Williamson Cc: chrisw@redhat.com, quintela@redhat.com, qemu-devel@nongnu.org, kvm@vger.kernel.org > > Not really. This identifier is device and bus independent, which is why > > I suggested passing the device to qemu_ram_alloc. This can then figure > > out how to the identify the device. It should probably do this the same > > way that we identify the saved state for the device. Currently I think > > this is an arbitrary vmstate name/id, but I expect this to change to a > > qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0"). > > Ok, that seems fairly reasonable, so from a device pointer we can get > something like "/i440FX-pcihost/pci.0/_addr_04.0", then we can add > something like ":rom" or ":bar.0" to it via an extra string. > > qemu_ram_alloc(DeviceState *dev, const char *info, size) Exactly - though personally I wouldn't call the second argument "info". > Does a function already exist to print out a qdev address path? No. I may have been a bit misleading here. What we really want to do is use the same matching algorithm as is used by the rest of the device state. Currently this is a vmstate name and [arbitrary] numeric id. I don't remember whether there's a convenient link from a device to its associated vmstate - if there isn't there probably should be. Paul