On Tue, Feb 12, 2008 at 04:33:03AM +0000, Daniel P. Berrange wrote:
> This patch adds support for the storage APIs to the remote driver
> client end. As with the network driver, things are configured such
> that all virtualization drivers will end up delegating to the remote
> driver for storage APIs. There's not much interesting to say about
> this patch since it just follows pattern for the existing APis.
[...]
> + if (conn &&
> + conn->driver &&
> + strcmp (conn->driver->name, "remote") == 0) {
aren't we supposed to use some STREQU macros for lisibility ?
> + /* If we're here, the remote driver is already
> + * in use due to a) a QEMU uri, or b) a remote
> + * URI. So we can re-use existing connection
> + */
> + conn->storagePrivateData = conn->privateData;
> + return VIR_DRV_OPEN_SUCCESS;
> + } else if (conn->networkDriver &&
> + strcmp (conn->networkDriver->name, "remote") == 0) {
same
> + conn->storagePrivateData = conn->networkPrivateData;
> + ((struct private_data *)conn->storagePrivateData)->localUses++;
> + return VIR_DRV_OPEN_SUCCESS;
> + } else {
> + /* Using a non-remote driver, so we need to open a
> + * new connection for network APIs, forcing it to
> + * use the UNIX transport. This handles Xen driver
> + * which doesn't have its own impl of the network APIs.
> + */
> + struct private_data *priv = malloc (sizeof(struct private_data));
> + int ret, rflags = 0;
> + if (!priv) {
> + error (NULL, VIR_ERR_NO_MEMORY, _("struct private_data"));
> + return VIR_DRV_OPEN_ERROR;
> + }
> + if (flags & VIR_CONNECT_RO)
> + rflags |= VIR_DRV_OPEN_REMOTE_RO;
> + rflags |= VIR_DRV_OPEN_REMOTE_UNIX;
> +
> + memset(priv, 0, sizeof(struct private_data));
hum, and use calloc to avoid malloc/memset ?
Except that i could not spot anything special, except it's not very fun
to read :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list