[libvirt] [PATCH RFC 0/5] Remove usb address set caching

Ján Tomko jtomko at redhat.com
Tue Aug 23 13:59:54 UTC 2016


On Sat, Aug 20, 2016 at 04:53:02PM +0200, Tomasz Flendrich wrote:
>During my work on removing addresses caching, usb addresses were added :).
>
>It should be applied on top of:
>https://www.redhat.com/archives/libvir-list/2016-August/msg00945.html
>or some small conflicts appear.
>
>I took an approach where exactly the same function is used to both
>calculate and recalculate the address set. It forces us to keep all
>the usb address handling in such state that reusing that function
>doesn't perform any changes that aren't needed.
>
>It might even be possible to unify the handling of usb devices into
>one function, "qemuDomainAssignUSBAddresses", and remove some code.
>For example, virDomainUSBAddressEnsure looks almost exactly like
>qemuDomainAssignUSBPorts plus virDomainUSBAddressReserve. The end goal
>would be simply calling qemuDomainAssignUSBAddresses() as many times
>as we want, for example when creating a new domain or after a hotplug.
>

I don't like calling functions that alter the whole domain definition
after hotplugging one device. We should be hotplugging a device that
is ready for the domain definition.

>To see what I mean, please take a look at qemuDomainAttachUSBMassStorageDevice.
>If I remove the call to virDomainUSBAddressEnsure and move creating the
>USB address set somewhere down (after virDomainDiskInsertPreAlloced),
>it works - the address is assigned flawlessly.
>Does it make any sense?
>
>
>Is there any reason why we don't add new usb hubs when hotplugging
>devices?
>

That kind of policy does not belong in libvirt, IMO.
We have made the mistake of auto-adding it for SCSI disks.
The problem is that the user might rather want to put it on a separate
USB controller, or just fail.

Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20160823/af2dbd11/attachment-0001.sig>


More information about the libvir-list mailing list