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 <[email protected]> > > --- > > 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?
pgpzPCqZNutG_.pgp
Description: PGP signature
-- libvir-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/libvir-list
