All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <ian.campbell@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xensource.com, Wei Liu <wei.liu2@citrix.com>,
	Eric Shelton <eshelton@pobox.com>
Subject: Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
Date: Mon, 9 Feb 2015 09:07:13 +0000	[thread overview]
Message-ID: <1423472833.23098.9.camel@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1502061719490.29696@kaball.uk.xensource.com>

On Fri, 2015-02-06 at 17:23 +0000, Stefano Stabellini wrote:
> > 
> > One of the main issues outstanding from when Anthony originally posted
> > his patches is how we want to go about building this?  I honestly do
> > not know how well the current dracut-based approach to building the
> > root image will work across various Linux distributions; perhaps it
> > will be OK, since all of the libraries that dracut will siphon in will
> > have to be in place to meet the build requirements for QEMU to begin
> > with. 
> >
> > However, I have zero knowledge about ARM-based Xen or where
> > NetBSD is used for dom0, and how they might affect the decisionmaking.
> > I also do not know what lessons have been learned from building other
> > stubdoms, rumpkernel, or Mirage that might inform these decisions.
> > In other words, what do you see as a sensible build scheme?  The
> > approach taken in the patches strikes me as too hacky for release
> > quality, but maybe it is OK...
>  
> It looks OK to me but I am not an expert in this kind of things. I'll
> let Ian Campbell and Ian Jackson (CC'ed) comment on it.

I'm not at all keen on things like the use of dracut (or mkinitramfs or
similar) in Xen's build since they are inherently/inevitably specific to
the Linux distro they came from, so they often don't work (or aren't
even available on) other Linux distros and are an even bigger problem
for *BSD.

I've yet to see a solution for this which seemed satisfactory enough to
be included in Xen's system. Mirage, minios stubdoms, rumpkernels etc
all avoid this by not having a need for a rootfs.

But, it's not necessarily the case that the Xen project has to produce
the Linux stubdom binary as part of its build output. IMHO it would be
sufficient (for tech preview at least) if the tools would detect and use
a stubdom binary if it were present at some well defined path so long as
the for the runes to build the image were documented somewhere (e.g.in
the wiki, in docs/misc, in some script, etc). Then the problems of them
being distro/kernel specific are somewhat mitigated (e.g. a Fedora fan
can write dracut instructions, a Debian fan can write mkinitramfs ones
and a BSD fan can make it work with a BSD kernel etc etc) and we avoid
having to have rootfs construction code in Xen's build.

Ian.

  reply	other threads:[~2015-02-09  9:07 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04  4:06 [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Eric Shelton
2015-02-04  4:06 ` [RFC 1/7] linux-stubdomain: Compile QEMU Eric Shelton
2015-02-06 15:46   ` Stefano Stabellini
2015-02-06 17:25     ` Eric Shelton
2015-02-06 17:27       ` Stefano Stabellini
2015-02-06 18:57       ` Wei Liu
2015-02-04  4:06 ` [RFC 2/7] linux-stubdomain: Compile Linux Eric Shelton
2015-02-06 15:51   ` Stefano Stabellini
2015-02-06 17:42     ` Eric Shelton
2015-02-06 17:45       ` Stefano Stabellini
2015-02-09  9:09         ` Ian Campbell
2015-05-14  9:08         ` George Dunlap
2015-05-14  9:28           ` Ian Campbell
2015-05-18 10:37             ` George Dunlap
2015-05-18 10:45               ` Ian Campbell
2015-05-18 10:55                 ` George Dunlap
2015-02-04  4:06 ` [RFC 3/7] linux-stubdomain: Build a disk image Eric Shelton
2015-02-06 15:57   ` Stefano Stabellini
2015-02-06 17:45     ` Eric Shelton
2015-02-04  4:06 ` [RFC 4/7] libxl: Add "stubdomain_version" to domain_build_info Eric Shelton
2015-02-06 16:06   ` Stefano Stabellini
2015-02-06 17:50     ` Eric Shelton
2015-02-06 17:54       ` Stefano Stabellini
2015-02-09  9:11   ` Ian Campbell
2015-02-09 14:11     ` Eric Shelton
2015-02-04  4:06 ` [RFC 5/7] libxl: Handle Linux stubdomain specific QEMU options Eric Shelton
2015-02-06 16:17   ` Stefano Stabellini
2015-02-04  4:06 ` [RFC 6/7] libxl: Build the domain with a Linux based stubdomain Eric Shelton
2015-02-06 16:33   ` Stefano Stabellini
2015-02-04  4:06 ` [RFC 7/7] libxl: Wait for QEMU startup in stubdomain Eric Shelton
2015-02-06 11:16   ` Wei Liu
2015-02-06 13:56     ` Eric Shelton
2015-02-06 14:59       ` Wei Liu
2015-02-06 15:36         ` Stefano Stabellini
2015-02-06 17:10           ` Eric Shelton
2015-02-06 17:23             ` Stefano Stabellini
2015-02-09  9:07               ` Ian Campbell [this message]
2015-02-09  9:14                 ` Stefano Stabellini
2015-02-09 12:08                 ` Anthony PERARD
2015-02-09 13:57                   ` Eric Shelton
2015-02-06 15:46         ` Eric Shelton
2015-02-06 16:12           ` Wei Liu
2015-02-06 15:42 ` [RFC 0/7] RFC Linux-based QEMU-upstream stub domain Stefano Stabellini

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=1423472833.23098.9.camel@citrix.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=eshelton@pobox.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=wei.liu2@citrix.com \
    --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.