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: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [xen-devel][RFC] xl disk configuration handling
From: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>
Date: Mon, 31 Jan 2011 15:19:33 -0500
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 31 Jan 2011 12:21:18 -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=d5vatuR8vsfe+qRDhz3A2ODNO/YZ1sGNA9uOMwXLiNI=; b=WU0Xw9O1Dvrw2xadCXpf+iB/VaHKhnBSSYF69UxkP/WRCLV6bdv9FXJFHJvBMvw0Xm CzlVcFV0p9mMMWZz2q9B0mU1yB1Rdk2j3eODcrKscqEKMNgxVFDGgSL4mdcW/wnCYumi Rw3zt2xGWOKTXZUWAbb6/rBOOKZRacRl2Kq34=
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=b1+CGVXuQ9sKHJtVy3iMeuh9Tx/NDDxNtIwThvdYNqVYrAI2D0Y+sLlN/vrI2aTBcX 1fe3WbgqkqlJ4kySuH7UEhYORoUq5IUnAcAxa6iYf5/iqamvVqx9LF4wYsLvh86ibu4q f7JfY80jmRb7gABq1MFnYvbO4PViWVirpaipE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1101311644090.7277@kaball-desktop>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20101027)
> 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).
I will switch to two enums instead of three.

> However I don't think libxl_disk_impl_type should be exposed at all, it
> should be up to libxl to decide whether AIO should be enabled or not. It
> might be useful to let the user disable the PV interface for a
> particular disk (that is what ioemu stands for), but it is too late for
> 4.1, let's just ignore ioemu for the moment.

> The backend types should be BLKBACK, TAPDISK2, and QEMU; TAPDISK refers
> to blktap1 that is not supported by libxl. However libxl uses "tap:" as
> backend string corresponding to TAPDISK2, I understand that might be
> confusing but I wouldn't change it now.
> Also it might be useful to retain the EMPTY format among the various
> libxl_disk_format's, it should reduce the overall amount of changes.
EMPTY, an indicator that there is no media in the cd-rom drive didn't really go
with the any of the enums which is why I removed it.  But later when I was
changing code I did find it inconvenient to check for both empty path plus
cdrom, so I will add it to disk format types though I am really not sure if it
belongs there.

> it would be nice if all the renaming was done in a separate patch so
> that the real changes are easier to read
I was worried you may not accept a patch with just renaming changes!  I could
separate interface changes (which would include renaming) from parsing and send
them as two separate patches. Would that be ok?


Stefano - I did go through your comments on a subset of code here but as I
mentioned in my earlier email, please ignore that code for now as I was going to
modify it anyway.  It was mostly to help understand the places that require
change plus for the code to compile.

> do we really need to change the parsing function that much? I
> understand there are significant changes but this is a total rewrite.
> I am concerned about all the bugs we might find later after the
> release...
This is one change I would really like to go with.  Not only does it help with
the changes we needed, it also gets rid of code duplication.  With this change
block-attach can rely on the same parsing code (that is once I submit the
block-attach changes patch).
> I would completely ignore "aio:" here.
> I would also ignore "ioemu:" the same way.
This redundant logic in block attach for parsing will be gone and disk parsing
logic will be reused.


Xen-devel mailing list

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