All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.