[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
From: |
Paul Brook |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() |
Date: |
Mon, 14 Jun 2010 14:09:06 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.4; x86_64; ; ) |
> > > "/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
> > 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. Device names have a restricted namespace, so we
can use an initial prefix to disambiguate a name/label from a bus address.
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).
Paul
- [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string, Alex Williamson, 2010/06/14
- [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(),
Paul Brook <=
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/14
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/14