On Thu, Oct 19, 2017 at 10:10:55AM +0200, Michal Privoznik wrote: > As discussed earlier [1], we should allow users to set device > aliases at the define time. While the discussed approach calls > for generating missing aliases too, I'm saving that for another > patch set. There are couple of reasons for that: > > a) I don't think it's really necessary (if users are interested > in a device they can just set the alias). > > b) This patch set is already big enough as is. > > c) Generating aliases is going to have its own problems. > > Therefore, for now I'm only proposing parsing user supplied > aliases. The idea is that it's not enabled by default for all > drivers. Any driver that want to/can provide this feature has to > set VIR_DOMAIN_DEF_FEATURE_USER_ALIAS. Note that we have some > drivers that don't have notion of device aliases. But the code is > generic enough so that it should be easy to use in the drivers > that do know what aliases are. This patch series missed some of the important parts of code that relies on our generated aliases: 1. qemuGetNextChrDevIndex() ... this will fail while attaching new chardev device without an alias if there is one already provided by user and doesn't match the one that we generate. 2. qemuAssignDeviceRedirdevAlias() ... same as 1) 3. qemuAssignDeviceShmemAlias() ... same as 1) 4. qemuDomainNetVLAN() ... similar to the previous ones, hot-plugging network interface with user alias will fail because the alias is used to figure out VLAN of the interface. Pavel
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
