From: George Dunlap <george.dunlap@citrix.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
"George Dunlap" <George.Dunlap@eu.citrix.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v2 0/7] libxl: add support for FreeBSD block hotplug scripts
Date: Mon, 29 Feb 2016 16:45:20 +0000 [thread overview]
Message-ID: <56D475A0.3040906@citrix.com> (raw)
In-Reply-To: <56D46D0B.7060908@citrix.com>
On 29/02/16 16:08, Roger Pau Monné wrote:
> El 29/2/16 a les 15:26, George Dunlap ha escrit:
>> On 29/02/16 12:18, Roger Pau Monné wrote:
>>> El 29/2/16 a les 13:15, George Dunlap ha escrit:
>>>> On Thu, Feb 25, 2016 at 7:25 PM, Roger Pau Monne <roger.pau@citrix.com> wrote:
>>>>> This series enables using hotplug scripts with the FreeBSD blkback
>>>>> implementation. Since FreeBSD blkback can use both block devices and regular
>>>>> RAW files as disks, the physical-device xenstore backend node is now
>>>>> OS-specific, Linux and NetBSD will encode the device major and minor numbers
>>>>> there, while FreeBSD simply puts an absolute path to a disk image.
>>>>
>>>> Just to catch me up here -- is this an incompatible thing that
>>>> FreeBSD *already* does, or something you're adding with this series?
>>>
>>> I assume you mean the usage of the "physical-device" node, right? In
>>> which case, this is something that I'm adding with this series (and some
>>> FreeBSD kernel changes, of course). Current FreeBSD code doesn't use
>>> physical-device at all.
>>
>> So there are cases where libxl could use the actual path to the
>> resulting device (if available) as well. Rather than overloading
>> physical-device, what about making a new node, with a path, that can be
>> used by all of them?
>>
>> I submitted such a patch here:
>>
>> <1439233885-22218-4-git-send-email-george.dunlap@eu.citrix.com>
>>
>> As part of a series allowing HVM domains to use hotplug scripts.
>>
>> Thoughts?
>
> TBH, I thought we were planning to use local attach to deal with both
> HVM guests with hotplug scripts and HVM guests using disks on driver
> domains. The solution you propose only solves the first part (hotplug
> scripts), but for disks coming from driver domains we would still need
> to use local-attach, so I would be in favour of always using local attach.
So the bootloader path basically has a feature where it says, "If you
can find a local path, just use it; otherwise do local attach". This
seems like a sensible path to take, as it avoids going through the whole
process of doing a local attach / detach when the disk is already
available. It seems like doing the same thing for qemu, and for disks
with hotplug scripts, makes a lot of sense.
Additionally, I doubt I'm going to have time to do anything wrt local
attach before 4.7; this (with the appropriate libxl additions) could
allow HVM guests for non-driver domains to have full parity with PV
guests in a relatively simple way.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-02-29 16:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-25 19:25 [PATCH v2 0/7] libxl: add support for FreeBSD block hotplug scripts Roger Pau Monne
2016-02-25 19:25 ` [PATCH v2 1/7] blkif: document how FreeBSD uses the physical-device backend node Roger Pau Monne
2016-03-01 12:39 ` Wei Liu
2016-03-01 18:17 ` Ian Jackson
2016-02-25 19:25 ` [PATCH v2 2/7] libxl: introduce an OS-specific function to get the physical-device Roger Pau Monne
2016-03-01 12:39 ` Wei Liu
2016-02-25 19:25 ` [PATCH v2 3/7] hotplug/FreeBSD: add block hotplug script Roger Pau Monne
2016-03-01 12:39 ` Wei Liu
2016-02-25 19:25 ` [PATCH v2 4/7] libxl/FreeBSD: add support for disk hotplug scripts Roger Pau Monne
2016-03-01 12:40 ` Wei Liu
2016-02-25 19:25 ` [PATCH v2 5/7] libxl: properly use vdev vs local device Roger Pau Monne
2016-03-01 12:40 ` Wei Liu
2016-02-25 19:25 ` [PATCH v2 6/7] libxl: add a FreeBSD implementation of libxl__devid_to_localdev Roger Pau Monne
2016-03-01 12:40 ` Wei Liu
2016-02-25 19:25 ` [PATCH v2 7/7] libxl: fix error message in local_device_attach_cb Roger Pau Monne
2016-03-01 12:40 ` Wei Liu
2016-02-29 12:15 ` [PATCH v2 0/7] libxl: add support for FreeBSD block hotplug scripts George Dunlap
2016-02-29 12:18 ` Roger Pau Monné
2016-02-29 14:26 ` George Dunlap
2016-02-29 16:08 ` Roger Pau Monné
2016-02-29 16:45 ` George Dunlap [this message]
2016-03-01 13:13 ` Roger Pau Monné
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=56D475A0.3040906@citrix.com \
--to=george.dunlap@citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).