All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@eu.citrix.com>
To: "Roger Pau Monné" <roger.pau@entel.upc.edu>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>
Subject: Re: [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks
Date: Thu, 29 Sep 2011 10:05:24 +0100	[thread overview]
Message-ID: <1317287124.26672.124.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <CAPLaKK5WGfthNCf5+vg76AsmJbC_3XthF1_nH3+UqtXPZLpHcA@mail.gmail.com>

On Thu, 2011-09-29 at 09:25 +0100, Roger Pau Monné wrote:
> I also think it's stupid to have two different programs watching
> xenstore, because that's what xenbackendd does. Instead, the code in
> xenbackendd could be move to libxl without much problem. The proper
> calls to the block, vif and other scripts can be added to
> libxl__device_destroy function to unplug vbd and network interfaces,
> but I don't know if that's the best place to put them, because I still
> don't have enough knowledge of libxl to decide that.

I think libxl__device_destroy is where they have to go right now,
because there are destroy code paths which don't go through code with
device-specific knowledge (specifically libxl__devices_destroy).

Now, I'd like to change that in the long run (so all destroy paths knows
about device specifics) but for now libxl__device_destroy will do.

>  As for the
> startup script, I have to look at the source to decide where to put
> them. Some advice about where would be the best place to put this
> calls is welcome.

I think libxl_device_disk_add() and libxl_device_nic_add() are the right
places.

The disk case is pretty trivial, I think, since you run the script
before setting up the backend and after tearing it down again.

The network case is a little trickier since you need to run the script
after the backend driver has created the actual device in dom0 so the
script can configure it (I presume this is much the same on NetBSD as
Linux). The existing hotplug scripts are obviously pretty good for this
(at least on Linux) since they are called at precisely the right time.
How does NetBSD manage that synchronisation today in xenbackendd? I'm
not sure how this can be done in an OS independent way and/or compatibly
with the existing backend implementations for each platform .

I'd have no problem with just tackling the block half now since it is
the more critical bit for NetBSD users.

There's a secondary issue of doing the right thing for
libxl_device_disk_local_(attach|detach) (to allow e.g. pygrub) but again
I think that could be left for the time being, fixing block devices for
regular use by domains is more important.

With regard to disabling the hotplug scripts/xenbackendd when this last
came up we decided that /etc/init.d/xencommons should be opting in on a
per-toolstack basis by touching a file (in /var/run or so) which the
hotplug script check before actually doing anything. In the NetBSD case
instead of touching a file I guess you start xenbackendd or not as
appropriate (or pass the right parameters etc).

That thread is "add a way to disable xen's udev script." from June,
you'll probably want to skip to the end, specifically
<19963.36234.366877.468293@mariner.uk.xensource.com>

Ian.

      reply	other threads:[~2011-09-29  9:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-16 15:36 [PATCH 0 of 2] Add NetBSD support for libxl PV DomU Roger Pau Monne
2011-09-16 15:36 ` [PATCH 1 of 2] hotplug: add hotplug-status disconnected Roger Pau Monne
2011-09-21  9:41   ` Ian Campbell
2011-09-16 15:36 ` [PATCH 2 of 2] libxl: add support for booting PV domains from NetBSD using raw files as disks Roger Pau Monne
2011-09-21  9:49   ` Ian Campbell
2011-09-27 17:01   ` Ian Jackson
2011-09-28  8:07     ` Roger Pau Monné
2011-09-28 13:28       ` Ian Jackson
2011-09-28  8:13     ` Ian Campbell
2011-09-28 13:32       ` Ian Jackson
2011-09-29  8:25         ` Roger Pau Monné
2011-09-29  9:05           ` Ian Campbell [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=1317287124.26672.124.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@eu.citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=roger.pau@entel.upc.edu \
    --cc=xen-devel@lists.xensource.com \
    /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.