All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Pau Monne <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Marek Marczykowski <marmarek@invisiblethingslab.com>,
	Joanna Rutkowska <joanna@invisiblethingslab.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v3 0/5] libxl: call hotplug scripts from libxl
Date: Mon, 23 Apr 2012 17:25:09 +0100	[thread overview]
Message-ID: <4F958265.9020107@citrix.com> (raw)
In-Reply-To: <1335189749.4347.27.camel@zakaz.uk.xensource.com>

Ian Campbell escribió:
> On Mon, 2012-04-23 at 14:31 +0100, Roger Pau Monne wrote:
>> Marek Marczykowski escribió:
>>> On 20.04.2012 15:23, Roger Pau Monne wrote:
>>>> This series removes the use of udev rules to call hotplug scripts when using
>>>> libxl. Scripts are directly called from the toolstack at the necessary points,
>>>> making use of the new event library and it's fork support.
>>> What about non-dom0 backends? There will be no simple way to execute script
>>> there by libxl without help from udev...
>> A new config option has been added on this series
>> (disable_xl_vif_scripts) that allows the user to keep executing vif
>> scripts from udev, so this functionality is not lost.
>
> In the long term (e.g. for 4.3) we intend to overhaul this in a way
> which makes driver domains work without udev at all, see "Driver domains
> communication protocol proposal" posted by Ian Jackson several weeks ago
> -- it would be good to confirm that the scheme proposed there works well
> for Qubes-OS too.
>
> In the short term (i.e. 4.2) we felt it was too late to be making these
> sorts of changes (e.g. implementing that complete protocol) and
> therefore the compromise is that xl will execute the scripts only in the
> case that dom0 is also the backend domain while for driver domains we
> retain the pre-4.2 behaviour of executing the hotplug scripts via udev
> inside the driver domain. This was necessary in order to fix things such
> as teardown of disks on NetBSD and teardown of NICs on openvswitch
> (currently both are broken even with backend = dom0 due to short comings
> in the previous approach) while not regressing the driver domain use
> case.
>
> By default do we write the xenstore key to suppress udev running the
> scripts regardless of which domain the backend is in or only for
> backend=0?

For vbd devices we write it everytime, for vifs devices we write it if 
disable_xl_vif_scripts is not set.

> Or is it necessary to use the override config option for
> driver domain?

So the new proposal is to add a disable_xl_vbd_scripts and to detect if 
the device backend is different than dom0, if it is in fact different 
than dom0 don't execute hotplug scripts from xl (this will only work for 
vifs, because there's no support for setting the device domain for vbd 
devices yet).

> Ian.
>
>>> In Qubes-OS we heavily use network backend in domU: dom0 have no network at
>>> all, all NICs are attached (as PCI device) to some domU - called NetVM, where
>>> network backend resides.
>> There should be no problem with that, you will just need to use the new
>> option.
>>
>>> Also vbd backend in domU is used - eg to boot HVM from iso, which is stored in
>>> some domU.
>> I didn't know you where able to use vbd from driver domains with xl, if
>> so I will have to add a similar option for vbd devices
>> (disable_xl_vbd_scripts).
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> http://lists.xen.org/xen-devel
>
>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2012-04-23 16:25 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-20 13:23 [PATCH v3 0/5] libxl: call hotplug scripts from libxl Roger Pau Monne
2012-04-20 13:23 ` [PATCH v3 1/5] libxl: allow libxl__exec to take a parameter containing the env variables Roger Pau Monne
2012-04-23 15:37   ` Ian Jackson
2012-04-20 13:23 ` [PATCH v3 2/5] libxl: add libxl__xs_path_cleanup Roger Pau Monne
2012-04-23 15:33   ` Ian Jackson
2012-04-23 15:42     ` Roger Pau Monne
2012-04-23 16:49       ` Ian Jackson
2012-04-23 16:52   ` Ian Jackson
2012-04-25 13:19     ` Roger Pau Monne
2012-05-02  9:44     ` Roger Pau Monne
2012-04-20 13:23 ` [PATCH v3 3/5] libxl: call hotplug scripts from libxl for vbd Roger Pau Monne
2012-04-23 16:48   ` Ian Jackson
2012-04-24  9:16     ` Ian Campbell
2012-04-24 10:09       ` Ian Jackson
2012-04-24 10:17         ` Ian Campbell
2012-04-24 10:27           ` Ian Jackson
2012-04-24 10:29             ` Ian Campbell
2012-04-24 10:37               ` Ian Jackson
2012-04-25 13:53                 ` Roger Pau Monne
2012-04-25 14:59                   ` Ian Campbell
     [not found]     ` <4F982F18.2080902@citrix.com>
2012-04-26 11:48       ` Fwd: " Roger Pau Monne
2012-04-26 12:06         ` Ian Campbell
2012-04-26 12:12           ` Roger Pau Monne
2012-04-26 13:02         ` Ian Jackson
2012-04-26 13:09           ` Ian Campbell
2012-05-11 16:06             ` Ian Jackson
2012-05-11 16:26               ` Ian Campbell
2012-04-20 13:23 ` [PATCH v3 4/5] libxl: call hotplug scripts from libxl for vif Roger Pau Monne
2012-04-23 16:59   ` Ian Jackson
2012-04-24  9:18     ` Ian Campbell
2012-04-25 11:19   ` Ian Campbell
2012-04-25 11:24     ` Roger Pau Monne
2012-04-20 13:23 ` [PATCH v3 5/5] libxl: add "downscript=no" to Qemu call Roger Pau Monne
2012-04-23 15:38   ` Ian Jackson
2012-04-23 12:12 ` [PATCH v3 0/5] libxl: call hotplug scripts from libxl Marek Marczykowski
2012-04-23 13:31   ` Roger Pau Monne
2012-04-23 13:47     ` Marek Marczykowski
2012-04-23 13:59       ` Non-dom0 block backends (was: Re: [PATCH v3 0/5] libxl: call hotplug scripts from libxl) Joanna Rutkowska
2012-04-23 14:02     ` [PATCH v3 0/5] libxl: call hotplug scripts from libxl Ian Campbell
2012-04-23 16:25       ` Roger Pau Monne [this message]
2012-04-24  9:18         ` Ian Campbell

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=4F958265.9020107@citrix.com \
    --to=roger.pau@citrix.com \
    --cc=Ian.Campbell@citrix.com \
    --cc=joanna@invisiblethingslab.com \
    --cc=marmarek@invisiblethingslab.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.