All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Jim Fehlig <jfehlig@suse.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH 3/3] libxl: libxl__device_from_disk should retrieve backend from xenstore
Date: Fri, 6 Mar 2015 13:04:45 +0000	[thread overview]
Message-ID: <20150306130445.GR12103@zion.uk.xensource.com> (raw)
In-Reply-To: <54EFB101.2030409@suse.com>

Sorry for the late reply.

On Thu, Feb 26, 2015 at 04:49:21PM -0700, Jim Fehlig wrote:
> Wei Liu wrote:
> > On Wed, Feb 11, 2015 at 10:18:18AM -0700, Jim Fehlig wrote:
> >   
> >> At minimum, libvirt will populate the pdev_path, vdev, backend, and
> >> format fields. If backend and format (which, in libvirt-speack
> >> correspond to the 'name' and 'type' attributes on the optional <driver>
> >> element) are not specified, they are set to LIBXL_DISK_BACKEND_UNKNOWN
> >> and LIBXL_DISK_FORMAT_RAW respectively.
> >>
> >>     
> >
> > Since libvirt has a tendency of specifying everything, how come there is
> > no "name" and "type" in <driver>?
> 
> The <driver> element is optional. From
> http://libvirt.org/formatdomain.html#elementsDisks
> 
> "|driver: |The optional driver element allows specifying further details
> related to the hypervisor driver used to provide the disk"
> 
> And when not specified, Ian C. recommended allowing libxl to pick
> suitable defaults
> 
> https://www.redhat.com/archives/libvir-list/2013-February/msg01126.html
> 
> >  Can we actually generate all the
> >   
> > fields needed when attaching a disk and store in libvirt's diskspec?
> 
> Yes, it was this way before the suggested change.
> 

I'm now of the opinion that we shouldn't change libxl__device_from_disk
to fill in specific information, otherwise it becomes a special case for
all the libxl__device_from_$foo  functions.

And from the information you provide above it seems to be easily fixable
on libvirt side -- you have all the information at hand when attaching
the disk, so why not just store it for reuse later?

Ian C, what do you think?

Wei.

> Regards,
> Jim

      reply	other threads:[~2015-03-06 13:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-09 13:21 [PATCH 0/3] Misc patches for libxl_device_disk functions Wei Liu
2015-02-09 13:21 ` [PATCH 1/3] libxl, xl: don't init/dispose when not necessary Wei Liu
2015-02-09 13:23   ` Wei Liu
2015-02-09 14:36     ` Wei Liu
2015-02-10 10:54   ` Ian Jackson
2015-02-10 11:39     ` Wei Liu
2015-02-09 13:21 ` [PATCH 2/3] libxl: factor out libxl__disk_backend_from_xs_be Wei Liu
2015-02-10 10:56   ` Ian Jackson
2015-02-10 11:39     ` Wei Liu
2015-02-09 13:21 ` [PATCH 3/3] libxl: libxl__device_from_disk should retrieve backend from xenstore Wei Liu
2015-02-10 11:01   ` Ian Jackson
2015-02-10 11:49     ` Wei Liu
2015-02-11 17:18       ` Jim Fehlig
2015-02-12 18:35         ` Ian Jackson
2015-02-23 15:13         ` Wei Liu
2015-02-26 23:49           ` Jim Fehlig
2015-03-06 13:04             ` Wei Liu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150306130445.GR12103@zion.uk.xensource.com \
    --to=wei.liu2@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=ian.campbell@citrix.com \
    --cc=jfehlig@suse.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.