On 06/16/2010 04:46 AM, 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.
Honestly, I think we've gone off the dee
Markus Armbruster writes:
> 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
Hi,
Bus names are chosen by the system as follows:
* If the driver of the parent device model provides a name, use that.
* Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
number, counting from zero in creation order.
* Else, use TYPE.NUM, where TYPE is derived from
On Thu, 2010-06-17 at 23:01 +0100, Paul Brook wrote:
> > > ### 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 mi
> > ### 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 frobn
I'm a little bit lost at how to implement something to print these
semantics, but a couple comments below...
On Wed, 2010-06-16 at 11:46 +0200, 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 m
Paul Brook writes:
>> > Bus names are chosen by the system as follows:
>> >
>> > * If the driver of the parent device model provides a name, use that.
>> >
>> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
>> >
>> > number, counting from zero in creation order.
>>
Paul Brook wrote:
>>> 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
>> Makes sense. We could attach this ID to the BusState (corresponding to
>> DeviceState:id) and manual
> > Bus names are chosen by the system as follows:
> >
> > * If the driver of the parent device model provides a name, use that.
> >
> > * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> >
> > number, counting from zero in creation order.
> >
> > * Else, use TYPE.NUM,
Markus Armbruster writes:
[...]
> Bus names are chosen by the system as follows:
>
> * If the driver of the parent device model provides a name, use that.
>
> * Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
> number, counting from zero in creation order.
>
> * Else, use
> > 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
>
> Makes sense. We could attach this ID to the BusState (corresponding to
> DeviceState:id) and manually set it during
Paul Brook wrote:
>> 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 curre
> 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
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 pr
14 matches
Mail list logo
