From: Eric Schwartz <eric.schwartz@hp.com>
To: Ian Pratt <Ian.Pratt@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: xm-test thoughts
Date: Thu, 03 May 2007 16:42:35 -0600 [thread overview]
Message-ID: <463A655B.8080201@hp.com> (raw)
In-Reply-To: <8A87A9A84C201449A0C56B728ACF491E0BA43F@liverpoolst.ad.cl.cam.ac.uk>
Ian Pratt wrote:
> Post a URL I can pull it from and I'll make sure it happens.
There's a (hopefully quick) legal sign-off that needs to happen first;
as soon as I get clearance, I'll let you know. This brings in a topic
I'd intended to include in the original email, and decided not to on
grounds of clarity: how xm-test images are created.
Right now, the process involves buildroot and uclibc, which works fine
for ppc and x86, but is fairly broken for ia64, and is in any event a
project designed for embedded systems. I assume uclibc was chosen
because it's relatively small compared to glibc, but with the patch in
my earlier email, any size ramdisk can be used. Since glibc is going to
be available, almost by definition, on any system on which Xen will be
built, would there be any interest in using that instead of buildroot
and uclibc?
Honestly, buildroot is kinda overkill for the purpose; it's trivial to
compile busybox and hping2 from scratch, and installing them into a
chroot shouldn't be particularly difficult. The only tricky thing is
glibc, since it is reasonably heavily-patched by most distributions, but
I'd argue even that isn't particularly hard; pick one distro's patches
(any distro would do; I used the Debian libc, but any distro's libc
should be fine) and go with that.
Another possibility, depending on how people feel about this, is to
simply require the binaries to exist on the system the ramdisk is built
from, and use a combination of ldd and python (or perl, or whatever, I
don't care) to copy all the required libraries into the image. This is
the method I used to create the image; I just didn't have an automated
process around it.
Is there any interest in either of these alternatives? Do most people
using xm-test just download a pre-generated image, or would efforts to
make images easier and faster to build be worth it? If nobody cares, I
don't want to waste my time, but I think making this process easier
would certainly help with Xen's portability.
-=Eric
next prev parent reply other threads:[~2007-05-03 22:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-03 19:18 xm-test thoughts Eric Schwartz
2007-05-03 21:13 ` Ian Pratt
2007-05-03 22:42 ` Eric Schwartz [this message]
2007-05-04 11:10 ` Tony Breeds
2007-05-04 15:42 ` Eric Schwartz
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=463A655B.8080201@hp.com \
--to=eric.schwartz@hp.com \
--cc=Ian.Pratt@cl.cam.ac.uk \
--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.