This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [xen-devel][RFC] xl disk configuration handling

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [xen-devel][RFC] xl disk configuration handling
From: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>
Date: Mon, 31 Jan 2011 15:39:05 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Delivery-date: Mon, 31 Jan 2011 12:40:00 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=QQpcJHnPo6lyICI+kcVBMv38ofNImy+1XNYxobM8qzM=; b=NpSz7X/u8Bm64vmKnPso+GAfgsuCehW/ZFHb+tp/BGApwOx0qbCX6A8hAZNOIOpmh5 2wZVTcxKS04r8K2ifiu86srmPuYfXg5T/b/D6LBmiYwAAhDXNvyycaE46gUHHZdKdllG ELYJqTlWQJ5tDHQLx6hwAs6afKrlRX7v95DyA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vdGt9PnHtnqmCw5MxUVzFpUvuQppmcVD1a22gxodNL82Ap2F7U5wY3La1CKusiMIYS o1KK701kMAD9EvqbTbKL7CeRhx5Ok3vjMCMYS9b4Dte0lMDEgIpOp4xqx5WyAqHOcDOd Uz720WmxQ5D2xh0OpRi7UZT2vcNle8U0oDyFc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1296501957.20804.198.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4D45A410.4000304@xxxxxxxxx> <alpine.DEB.2.00.1101311644090.7277@kaball-desktop> <1296501957.20804.198.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20101027)
Ian Campbell wrote:
> On Mon, 2011-01-31 at 17:18 +0000, Stefano Stabellini wrote: 
>> I agree that libxl_disk_phystype expresses both the format and the
>> backend type in a single confusing way, so there should be two enums:
>> one for the format (libxl_disk_format) and one for the backend type
>> (libxl_disk_pdev_type).
> pdev_type doesn't seem like a very good name for "backend type" (and it
> is unnecessarily abbreviated which I personally dislike, especially in
> public interfaces).
> Would libxl_disk_backend_type work?
Yes, I will go with libxl_disk_backend_type.

>>> diff -r 52e928af3637 tools/libxl/libxl.c
>>> --- a/tools/libxl/libxl.c     Fri Jan 28 19:37:49 2011 +0000
>>> +++ b/tools/libxl/libxl.c     Sun Jan 30 11:47:22 2011 -0500
>>> @@ -588,7 +588,7 @@ int libxl_wait_for_disk_ejects(libxl_ctx
>>>      for (i = 0; i < num_disks; i++) {
>>>          if (asprintf(&(waiter[i].path), "%s/device/vbd/%d/eject",
>>>                       libxl__xs_get_dompath(&gc, domid),
>>> -                     libxl__device_disk_dev_number(disks[i].virtpath)) < 0)
>>> +                     libxl__device_disk_dev_number(disks[i].vdev_path)) < 
>>> 0)
>>>              goto out;
>>>          if (asprintf(&(waiter[i].token), "%d", LIBXL_EVENT_DISK_EJECT) < 0)
>>>              goto out;
>> it would be nice if all the renaming was done in a separate patch so
>> that the real changes are easier to read
> Aren't the renamings a bit cosmetic anyway, i.e. could/should be left
> for 4.2? I guess I can see the argument of changing the field name if
> the type name changes, assuming the type names are well chosen.
I did consider keeping away from such renaming but then I figured I might as
well if I am going to make other changes to the interface.

> The virtpath->vdev_path rename in particular seems odd. The main thing
> which is wrong with virtpath is that the thing it contains is a vdev
> which doesn't really have any path-like properties, but we retain the
> path part in the new name. If it's renamed to anything I reckon it
> should just be vdev.
That makes sense.  I will rename it to just vdev.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>