[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: RFC qdev path semantics
From: |
Paul Brook |
Subject: |
[Qemu-devel] Re: RFC qdev path semantics |
Date: |
Wed, 16 Jun 2010 12:45:27 +0100 |
User-agent: |
KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.4; x86_64; ; ) |
> Markus Armbruster wrote:
> > A number of changes to qdev paths have been proposed in various threads.
> > It's becoming harder to keep track of them, so let me sum them up in one
> > place. Please correct me if I misrepresent your ideas.
> >
> > I'm going to describe the current state of things, and the proposed
> > changes (marked with ###).
> >
> >
> > The device tree has the main system bus as root. A child of a bus is a
> > device. A child of a device is a bus.
> >
> > A qdev path consists of qdev path components separated by '/'. It
> > resolves to a node in the device tree, either bus or device.
> >
> > The qdev path "/" resolves to the root, i.e. the main system bus.
>
> Another aspect: A path may start with an arbitrary bus name, not only
> the system bus. Although this is ambiguous, we need to keep it for
> addressing the bus itself due to existing client use. But, IMO, we
> should at least start deprecating this for addressing elements below
> that bus (e.g. "pci.0/e1000").
I think this would be better served by adding explicit aliases/IDs for those
use-cases. i.e. define the global ID "pci.0" to be an alias for
/i440FX-pcihost/pci
Paul
RFC qdev path semantics (was: [Qemu-devel] [RFC PATCH 0/5] Introduce canonical device hierarchy string), Markus Armbruster, 2010/06/16
[Qemu-devel] Re: RFC qdev path semantics, Markus Armbruster, 2010/06/16
[Qemu-devel] Re: RFC qdev path semantics, Alex Williamson, 2010/06/17
[Qemu-devel] Re: RFC qdev path semantics, Gerd Hoffmann, 2010/06/18