From: Anthony PERARD <anthony.perard@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>,
Eric Shelton <eshelton@pobox.com>, Wei Liu <wei.liu2@citrix.com>,
xen-devel@lists.xensource.com,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [RFC 7/7] libxl: Wait for QEMU startup in stubdomain
Date: Mon, 9 Feb 2015 12:08:22 +0000 [thread overview]
Message-ID: <20150209120822.GC1740@perard.uk.xensource.com> (raw)
In-Reply-To: <1423472833.23098.9.camel@citrix.com>
On Mon, Feb 09, 2015 at 09:07:13AM +0000, Ian Campbell wrote:
> 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'd like to precise that the use of dracut here is only to copy a binary
and it's dependencies (shared libraries), the binary used is called
dracut-installer. I guest that the same can be achieved by the copy_exec()
function from mkinitramfs (found in
/usr/share/initramfs-tools/hook-functions on a debian system).
The rest is done by a script, which choose which binary and file to include
in the rootfs, where to put them and how to generate the image.
--
Anthony PERARD
next prev parent reply other threads:[~2015-02-09 12:08 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
2015-02-09 9:14 ` Stefano Stabellini
2015-02-09 12:08 ` Anthony PERARD [this message]
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=20150209120822.GC1740@perard.uk.xensource.com \
--to=anthony.perard@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=eshelton@pobox.com \
--cc=ian.campbell@citrix.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.