WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] xm-test domain creation delay

To: Ewan Mellor <ewan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] xm-test domain creation delay
From: Dan Smith <danms@xxxxxxxxxx>
Date: Mon, 14 Nov 2005 08:28:48 -0800
Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 14 Nov 2005 16:29:09 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20051114161025.GE16045@xxxxxxxxxxxxxxxxxxxxxx> (Ewan Mellor's message of "Mon, 14 Nov 2005 16:10:25 +0000")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20051114154823.GD16045@xxxxxxxxxxxxxxxxxxxxxx> <87fypzi5ix.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> <20051114161025.GE16045@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)
EM> Well it would be better if we could compile and link against the
EM> version of libc in the ramdisk!

That's true for the libc case, but not for libxenctrl, right?

EM> How do all the other applications in the ramdisk get compiled now?

I believe that the only application on the ramdisk at the moment is
busybox, which is static.  uClibc is on there as well, since the
buildroot system can optionally download, compile, and link other
applications into the ramdisk automatically.

EM> Is it sufficient to say that once you can connect the console,
EM> then the guest is ready for commands? 

Well, not in the "xm console" sense, but in the xm-test console
library, this is true.  The xm-test console library isn't connected
and passed back to the test until it has seen the special shell
prompt.  So, this means the DomU is actually ready for commands.

EM> That wouldn't be the case for a "real" guest, of course, but if
EM> that's OK for xm-test (or close enough that we only need a 1
EM> second timeout or something) then that sounds like a better idea.

Right, which is why I asked if this sort of thing would be needed in a
generic sense.

I'm testing the modification to the console right now, which seems to
be working on my machine. 

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms@xxxxxxxxxx


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel