[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: RFC qdev path semantics
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Re: RFC qdev path semantics |
Date: |
Wed, 16 Jun 2010 16:31:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Paul Brook <address@hidden> 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 TYPE.NUM, where TYPE is derived from the bus type, and NUM
>> >
>> > is the bus number, as above.
>> >
>> > ### Paul proposes to drop ID.NUM.
>>
>> ABI change: "-device lsi,id=my-scsi -device scsi-disk,bus=my-scsi.0" no
>> longer works.
>
> IMO this is a fundamentally broken ABI, so I don't care.
Users of this ABI won't appreciate that attitude.
I do support dropping ID.NUM, but we owe our users due ABI diligence.
>> > ### Paul proposes to either drop TYPE.NUM (and require drivers to
>> > provide bus names), or make NUM count separately for each bus type.
>>
>> Likewise.
>
> I'd be surprised if anyone actually uses absolute device paths at this time,
> and they're probably going to be broken by other changes.
Yes.
> Using these default bus names as global identifiers is fixable using aliases
> (e.g. -device lsi,bus=pci.0). I'd expect this to cover most interesting uses.
> See http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg02149.html
Keeping the old bus names work for the buses we create automatically
shouldn't be hard. Only a few, and no ID.NUM there. It's the
user-created buses that worry me.
- [Qemu-devel] Re: [RFC PATCH 0/5] Introduce canonical device hierarchy string, (continued)
[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
[Qemu-devel] Re: RFC qdev path semantics, Markus Armbruster, 2010/06/18
[Qemu-devel] Re: RFC qdev path semantics, Anthony Liguori, 2010/06/22