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] libxl: problem with devices in PV

To: Roger Pau Monné <roger.pau@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] libxl: problem with devices in PV
From: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Date: Thu, 21 Jul 2011 11:36:27 +0100
Cc: Christoph Egger <Christoph.Egger@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 21 Jul 2011 03:37:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <CAPLaKK63-QUxV7s37m54+xzoW4_3GP+LhELT2ev8=+EA76BhSg@xxxxxxxxxxxxxx>
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>
Organization: Citrix Systems, Inc.
References: <CAPLaKK7gAGfazKmyywfdwjFGBS+xog4C5M8bEzvhM3NyM=5mYA@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1107201230260.12963@kaball-desktop> <1311166476.20648.194.camel@xxxxxxxxxxxxxxxxxxxxxx> <CAPLaKK6zQzyn7+Dgt0MZss_3WhMLVTOGkrBkZS89JpPq57emFQ@xxxxxxxxxxxxxx> <1311168600.20648.217.camel@xxxxxxxxxxxxxxxxxxxxxx> <4E26E5BB.1020902@xxxxxxx> <CAPLaKK6EMG13iLt3ceWjwMj10ung4x5D8XQ+c45wzNW_Z13sKg@xxxxxxxxxxxxxx> <1311239027.32010.64.camel@xxxxxxxxxxxxxxxxxxxxxx> <CAPLaKK7gY1juGDtNcn+Zrcv-PwVxYnU=jF0fhu2vtAHeFFzEkQ@xxxxxxxxxxxxxx> <CAPLaKK63-QUxV7s37m54+xzoW4_3GP+LhELT2ev8=+EA76BhSg@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-07-21 at 10:39 +0100, Roger Pau Monné wrote:
> BTW, would it be ok to create a new disk backend, like LOOP or VND
> Now it's a bit hackish, since type is always set to phy, I have to
> guess the real type by checking if  'params' starts with '/dev' on
> xenbackend. I think it would be clearer to set the type to
> LIBXL_DISK_BACKEND_VND if passed file is not a block device and OS is
> NetBSD in disk_try_backend.

The VND stuff is transparent to the toolstack though, it's internal to
xenbackendd and the hotplug scripts, all the toolstack sees is a vbd
directory in xenstore. So I think it would be better to stick with the
phy/vbd types within the toolstack.

Can the code in disk_try_backend become:

[in some suitable central location:]
#if __NetBSD__

        if (!(a->disk->format == LIBXL_DISK_FORMAT_RAW ||
              a->disk->format == LIBXL_DISK_FORMAT_EMPTY)) {
            goto bad_format;
        if (a->disk->format == LIBXL_DISK_FORMAT_EMPTY)
            return backend;

        if (S_ISREG(a->stab.st_mode)) /* S_ISLNK? */
            return backend;
        if (S_ISBLK(a->stab.st_mode))
            return backend;

        LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "Disk vdev=%s, backend phy"
                   " unsuitable as phys path not a block device"
#ifdef HAVE_PHY_...
                   " nor a regular file"
                   , a->disk->vdev);
        return 0;

? (perhaps the log message construction could be done cleaner)


Xen-devel mailing list