From: Alex Williamson <alex.williamson@redhat.com>
To: Paul Brook <paul@codesourcery.com>
Cc: chrisw@redhat.com, kvm@vger.kernel.org,
Markus Armbruster <armbru@redhat.com>,
qemu-devel@nongnu.org, avi@redhat.com, kraxel@redhat.com
Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
Date: Mon, 14 Jun 2010 09:29:10 -0600 [thread overview]
Message-ID: <1276529350.12015.136.camel@x201> (raw)
In-Reply-To: <201006141409.08653.paul@codesourcery.com>
On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
> > > > "/main-system-bus/pci.0,addr=09.0/virtio-blk-pci"
>
> There's a device missing between the main system bus and the pci bus. Should
> be something like:
>
> /main-system-bus/piix4-pcihost/pci.0/_09.0
Ok, I can easily come up with:
/System/main-system-bus/i440FX-pcihost/PCI/pci.0/_09.0/virtio-blk-pci/virtio-blk
to expand the previous output. Code below.
> > > Could you explain why you add "identified properties of the immediate
> > > parent bus and device"? They make the result ver much *not* a "dev
> > > path" in the qdev sense...
> >
> > In order to try to get a unique string. Without looking into device
> > properties, two e1000s would both be:
> >
> > /main-system-bus/pci.0/e1000
> > /main-system-bus/pci.0/e1000
> >
> > Which is no better than simply "e1000" and would require us to fall back
> > to instance ids again. The goal here is that anything that makes use of
> > passing a dev when registering a vmstate gets an instance id of zero.
>
> You already got the information you need, you just put it in the wrong place.
> The canonical ID for the device could be its bus address. In practice we'd
> probably want to allow the user to specify it by name, provided these are
> unique. e.g. in the above machine we could accept [...]/virtiio-blk-pci would
> as an aias for [...]:_09.0.
Sure, if there was a guaranteed unique char* on a DeviceState that was
consistent between guest invocations, we could just use that instead. I
suppose all devices could have a global system id property and if that
was present we'd use that instead of creating the device path.
> Device names have a restricted namespace, so we
> can use an initial prefix to disambiguate a name/label from a bus address.
I'm not sure it's necessary. It seems like it would only be necessary
to differentiate the two if we wanted to translate between namespaces.
But I think it's reasonable to require that if a global name is
provided, it must always be provided for the life of the VM.
> For busses that don't have a consistent addressing scheme then some sort of
> instance ID is unavoidable. I guess it may be possible to invent something
> based on other device properties (e.g. address of the first IO port/memory
> region).
Instance IDs aren't always bad, we just run into trouble with hotplug
and maybe creating unique ramblock names. But, such busses typically
don't support hotplug and don't have multiple instances of the same
device on the bus, so I don't expect us to hit many issues there as long
as we can get a stable address path. Thanks,
Alex
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
---
static int qdev_strprint_path_props(DeviceState *dev, Property *props,
char *buf, size_t len)
{
int offset = 0;
char pbuf[64];
if (!props)
return 0;
while (props->name) {
if (props->info->flags & PROP_FLAG_PATH) {
if (props->info->print) {
props->info->print(dev, props, pbuf, sizeof(pbuf));
offset += snprintf(buf + offset, len - offset, "/_%s", pbuf);
}
}
props++;
}
return offset;
}
static int qdev_strprint_dev(DeviceState *dev, char *buf, size_t len);
static int qdev_strprint_bus(DeviceState *dev, char *buf, size_t len)
{
int offset = 0;
if (dev->parent_bus->parent)
offset += qdev_strprint_dev(dev->parent_bus->parent, buf, len);
offset += snprintf(buf + offset, len - offset, "/%s/%s",
dev->parent_bus->info->name, dev->parent_bus->name);
offset += qdev_strprint_path_props(dev, dev->parent_bus->info->props,
buf + offset, len - offset);
return offset;
}
static int qdev_strprint_dev(DeviceState *dev, char *buf, size_t len)
{
int offset = 0;
if (dev->parent_bus)
offset += qdev_strprint_bus(dev, buf, len);
offset += snprintf(buf + offset, len - offset, "/%s", dev->info->name);
offset += qdev_strprint_path_props(dev, dev->info->props,
buf + offset, len - offset);
if (dev->id)
offset += snprintf(buf + offset, len - offset, "/%s", dev->id);
return offset;
}
char *qdev_get_dev_path(DeviceState *dev)
{
char buf[256] = "";
if (!dev)
return NULL;
qdev_strprint_dev(dev, buf, sizeof(buf));
return qemu_strdup(buf);
}
next prev parent reply other threads:[~2010-06-14 15:29 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-14 5:51 [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() Alex Williamson
2010-06-14 6:39 ` Markus Armbruster
2010-06-14 12:52 ` Alex Williamson
2010-06-14 13:00 ` Jan Kiszka
2010-06-14 13:09 ` Paul Brook
2010-06-14 15:29 ` Alex Williamson [this message]
2010-06-14 15:42 ` Paul Brook
2010-06-14 16:00 ` Jan Kiszka
2010-06-14 16:38 ` Alex Williamson
2010-06-14 16:49 ` Jan Kiszka
2010-06-14 18:35 ` Alex Williamson
2010-06-14 21:43 ` Paul Brook
2010-06-14 22:11 ` Alex Williamson
2010-06-14 22:46 ` Paul Brook
2010-06-15 1:14 ` Alex Williamson
2010-06-15 11:24 ` Paul Brook
2010-06-15 8:47 ` Markus Armbruster
2010-06-15 9:34 ` Jan Kiszka
2010-06-15 11:28 ` Paul Brook
2010-06-15 11:45 ` Jan Kiszka
2010-06-15 12:04 ` Paul Brook
2010-06-15 12:16 ` Jan Kiszka
2010-06-15 12:39 ` Paul Brook
2010-06-15 13:00 ` Jan Kiszka
2010-06-15 13:14 ` Paul Brook
2010-06-15 13:16 ` Markus Armbruster
2010-06-15 13:32 ` Jan Kiszka
2010-06-15 20:53 ` Alex Williamson
2010-06-15 21:55 ` Paul Brook
2010-06-15 22:33 ` Alex Williamson
2010-06-15 23:01 ` Paul Brook
2010-06-15 23:10 ` Alex Williamson
2010-06-16 0:25 ` Chris Wright
2010-06-16 0:30 ` Paul Brook
2010-06-16 0:35 ` Chris Wright
2010-06-16 1:30 ` Paul Brook
2010-06-16 2:55 ` Alex Williamson
2010-06-16 8:23 ` Markus Armbruster
2010-06-17 22:25 ` Alex Williamson
2010-06-18 9:16 ` Jan Kiszka
2010-06-18 15:01 ` Alex Williamson
2010-06-18 15:22 ` Jan Kiszka
2010-06-18 14:03 ` Markus Armbruster
2010-06-18 14:14 ` Jan Kiszka
2010-06-18 15:21 ` Alex Williamson
2010-06-15 11:42 ` Markus Armbruster
2010-06-15 11:59 ` Jan Kiszka
2010-06-15 13:07 ` Markus Armbruster
2010-06-15 13:19 ` Paul Brook
2010-06-15 13:32 ` Paul Brook
2010-06-15 15:08 ` Jan Kiszka
2010-06-16 13:02 ` Markus Armbruster
2010-06-14 5:51 ` [Qemu-devel] [RFC PATCH 2/5] savevm: Add DeviceState param Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] [RFC PATCH 3/5] savevm: Make use of the new " Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] [RFC PATCH 4/5] eepro100: Add a dev field to eeprom new/free functions Alex Williamson
2010-06-14 5:51 ` [Qemu-devel] [RFC PATCH 5/5] virtio-net: Incorporate a DeviceState pointer and let savevm track instances Alex Williamson
2010-06-14 7:02 ` [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string Gerd Hoffmann
2010-06-14 19:56 ` Alex Williamson
2010-06-15 8:53 ` Markus Armbruster
2010-06-15 18:01 ` Alex Williamson
2010-06-16 8:34 ` Markus Armbruster
2010-06-16 8:36 ` Markus Armbruster
2010-06-15 9:12 ` Gerd Hoffmann
2010-06-15 18:03 ` Alex Williamson
2010-06-16 9:46 ` RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string) Markus Armbruster
2010-06-16 10:40 ` Paul Brook
2010-06-16 11:37 ` [Qemu-devel] Re: RFC qdev path semantics Jan Kiszka
2010-06-16 11:45 ` Paul Brook
2010-06-16 12:01 ` Jan Kiszka
2010-06-16 12:21 ` Paul Brook
2010-06-16 13:50 ` Jan Kiszka
2010-06-16 13:05 ` Markus Armbruster
2010-06-16 13:23 ` Paul Brook
2010-06-16 14:31 ` Markus Armbruster
2010-06-17 21:43 ` Alex Williamson
2010-06-17 22:01 ` Paul Brook
2010-06-17 22:34 ` Alex Williamson
2010-06-18 7:52 ` Gerd Hoffmann
2010-06-18 14:58 ` Markus Armbruster
2010-06-22 14:27 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1276529350.12015.136.camel@x201 \
--to=alex.williamson@redhat.com \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=chrisw@redhat.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).