On Wed, Mar 24, 2010 at 11:46:24AM +0000, Daniel P. Berrange wrote:
> To allow the new virDomainUpdateDeviceFlags() API to be universally
> used with all drivers, this patch adds an impl to all the current
> drivers which support CDROM or Floppy disk media change via the
> current virDomainAttachDeviceFlags API
>
> * src/qemu/qemu_driver.c, src/vbox/vbox_tmpl.c,
> src/xen/proxy_internal.c, src/xen/xen_driver.c,
> src/xen/xend_internal.c: Implement media change via the
> virDomainUpdateDeviceFlags API
> * src/xen/xen_driver.h, src/xen/xen_hypervisor.c,
> src/xen/xen_inotify.c, src/xen/xm_internal.c,
> src/xen/xs_internal.c: Stubs for Xen driver entry points
[...]
> +static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
> + const char *xml,
> + unsigned int flags)
> +{
[...]
> + switch (dev->data.disk->device) {
> + case VIR_DOMAIN_DISK_DEVICE_CDROM:
> + case VIR_DOMAIN_DISK_DEVICE_FLOPPY:
> + ret = qemudDomainChangeEjectableMedia(driver, vm, dev->data.disk);
> + if (ret == 0)
> + dev->data.disk = NULL;
> + break;
> +
> +
> + default:
> + qemuReportError(VIR_ERR_NO_SUPPORT,
> + _("disk bus '%s' cannot be updated."),
> + virDomainDiskBusTypeToString(dev->data.disk->bus));
> + break;
> + }
> +
> + if (ret != 0 && cgroup) {
> + virCgroupDenyDevicePath(cgroup,
> + dev->data.disk->src);
> + }
Hum ... I got a bit lost there, qemudDomainChangeEjectableMedia only
returns -1 on error or 0 on success. But failure to change may mean that
the previous data is still being used, shouldn't we check that the
old and new data.disk->src are different before denying access ?
But it's a minor question,
ACK,
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list