On Fri, Oct 07, 2005 at 02:40:27PM -0500, Hollis Blanchard wrote:
> On Friday 07 October 2005 12:38, Hollis Blanchard wrote:
> > On Monday 03 October 2005 17:52, Dan Smith wrote:
> > > We would like some feedback from the community on the usefulness of
> > > our framework, in hopes that it might be hosted by xensource so that
> > > everyone can contribute tests to help harden xm and xend.
> >
> > Building xm-test takes a very long time, because among other things it
> > takes it upon itself to download and build its very own toolchain. That is
> > extremely silly; please have it use the existing toolchain instead.
>
> To summarize IRC conversation:
Some responses, as I think your summary has a lot of personal commentary,
and I want to make sure another perspective is stated.
> - xm-test creates an initrd that's used to boot the test DomUs.
> - That initrd is created with buildroot[1], which uses uClibc, which requires
> building a whole new toolchain to use.
Corrent, the initrd uses buildroot, which is a generic tool for building
embedded Linux system images. It is open source, easy to extend, and
brought to you by the same people that brought you busybox & uClibc.
> - If they know how, users can manually copy the initrd from one xm-test
> directory to another, avoiding the need to rebuild it.
Correct. Even if they don't know the build process is 100% automated, it
just takes time. Given then number of people on xen-devel running gentoo,
not sure why an "ug, it has to compile?" sentiment kept coming up on IRC. ;)
> - The initrd is plain busybox, which could easily be statically linked with
> the user's GNU libc.
For now, we are only 6 weeks and 80 tests into this, and don't even have
full coverage for xm user commands at this point.
> - In the future, people want to install other tools (like e2fsprogs) into the
> ramdisk. These could also be statically linked with GNU libc.
Niv talked about hping, and other more advanced network tools. Saying
everything needs to be statically linked is sort of a bear for adding new
bits. There is already a very modular way to add things to buildroot. We
can use that our play a NIH game and reinvent it for static binaries. I
prefer to stand on the shoulders of those that came before me.
> - Other than statically linking, the user's libc.so could be copied to the
> initrd, which doesn't make for a very reliable testing environment.
This is a retched idea. We actually did this in systemimager, and then you
start finding all the joys of the differences in glibc between distros and
versions, and have to go through the joys of mklibs (a debian shared library
dependency tool) to ensure you've copied over all the right bits. It really
sucks, and breaks quite a bit.
> - Using uClibc makes the initrd smaller, which is of dubious value in this
> environment.
Unless you use it for scale out testing (i.e. run 100 DomU). Then the
memory size is important as your root is in memory. I think Dan was able to
start just under 100 DomU with xm-test on his 2 GB workstation (kinda cool
:))
> - initrd images are limited in size, while initramfs images are not.
Yep, initramfs is a good thing to look into. We did initrds because we'd
all done initrds before, and they were a well known quantity. :)
While some heathly debate on any subject is always a good thing, it is worth
noting we tried a lot of these other approaches to begin with, and none of
them really panned out in a useful way. We could spend all our time
creating the *uber static link initrd*, but that's the least interesting
part of xm-test. :) The actual tests are where we need to focus.
Optimizing the plumbing can come post 3.0.
-Sean
--
__________________________________________________________________
Sean Dague Mid-Hudson Valley
sean at dague dot net Linux Users Group
http://dague.net http://mhvlug.org
There is no silver bullet. Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
pgpLz7FLyFoxv.pgp
Description: PGP signature
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home