On Fri, Feb 06, 2015 at 05:36:40PM +0000, Daniel P. Berrange wrote:
> On Thu, Feb 05, 2015 at 06:17:08AM +0100, Marek Marczykowski-Górecki wrote:
> > At least Xen supports backend drivers in another domain (aka "driver
> > domain"). This patch introduces XML config option for such setting as
> > 'domain' attribute of 'source' element. Verification its content is left
> > for the driver.
> >
> > In the future same option will be needed for USB devices (hostdev
> > objects), but for now libxl doesn't have support for PVUSB.
> >
> > Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> > ---
> > Changes in v2:
> > - describe in docs/formatdomain.html.in
> > - enforce empty domain tag (only 'name' attribute allowed)
> >
> > Changes in v3:
> > - change <domain name='xx'/> element to domain='' attribute of source
> > element - this is more logical place
> > - grammar of docs
>
> I hate to say this, but I think the previous way you had it was
> a better approach. A <domain name='xxxx'/> element is something
> we can potentially add to any type of device, whereas the
> <source domain='xxx'> approach will need to have different
> XML for each type of device as they don't all have a <source>
> element present.
Ok, but perhaps some better name? When I read something like:
<interface type='bridge'>
<ip address='1.2.3.4'/>
<domain name='netvm'/>
</interface>
it is really not obvious what domain this is about. When the same would
be supported for PCI passthrough, it will be even more confusing:
<interface type='hostdev' managed='yes'>
<driver name='vfio'/>
<source>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</source>
<mac address='52:54:00:6d:90:02'/>
<domain name='netvm'/>
</interface>
Any ideas for a better name?
--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Attachment:
pgpIj9rtTc0Hm.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list