Re: RFC qdev path semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > 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.
 
> > ### 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.

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

Paul
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux