Re: [Qemu-devel] inconsistency between device traversal in qdev and legacy

[Markus Armbruster]

Gerd Hoffmann <address@hidden> writes:

>   Hi,
>
> Peter Maydell <address@hidden> writes:
> 
>> If you have a model with more than one USB bus, and you
>> create a USB device on the command line without specifying
>> which bus to plug it into, QEMU will choose a different bus
>> depending on whether you use the legacy "-usbdevice keyboard"
>> or the qdev "-device usb-kbd".
>> 
>> This is because the legacy option finds the USB bus with
>> usb_bus_find(), which searches the 'busses' list, which is
>> populated by usb_bus_new(), with each new bus added to the
>> tail of the list. The qdev option looks for the USB bus
>> with qbus_find_recursive(), which walks the qdev tree.
>> Since qbus_create_inplace() adds each new child bus to
>> the front of the parent's child_bus list, this means that
>> qbus_find_recursive() will encounter the last-added bus
>> first, whereas usb_bus_find() will get the first-added bus.

The fact that we duplicate qtree information in a separate list "busses"
either means we've been too lazy to garbage collect busses, or we've
failed to make working with the qtree as easy as it should be.

> Quite a while back I've tried to switch qdev from QLIST to QTAILQ
> exactly to allow adding stuff to the tail of the lists(s), because
> that feels more natural to me than the current ordering.  "info qtree"
> is upside-down too ;)

Has always annoyed me.  Let's bite the bullet and change it.

> Gave up after resending it one or two times, the forgot about it,
> wasn't *that* important to me.

Still got a pointer to the patch?

qdev is too important to continue much longer without a maintainer.

>> I assume this is likely to apply to other bus types as well.
>>
>> Is there anything we can do to fix this inconsistency [*],
>> or are we tied to the existing enumeration orders in both
>> cases for compatibility with users with currently-working
>> command lines or configurations?
>
> Could be we break something.  I think it is unlikely though.  Multiple
> busses of the same type are pretty uncommon, and any examples with
> multiple lsi adapters (for example) advertise explicitly assign
> devices via bus=.  libvirt uses bus= everywhere too.

The sooner we fix up the order, the less stuff we'll break.

>> [*] the actual code changes are simple enough, obviously

Care to cook up a patch?