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

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Mon, Nov 14, 2005 at 08:28:48AM -0800, Dan Smith wrote:

> 
> 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?

Well of course you'd need to compile libxenctrl (and libxenstore) for that
environment too.

> 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.

Of course!  I'd forgotten about the special shell prompt hack.  Well that
seems like a much easier way to do it.

> 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.

Yes, it would be nice for more general cases, but that of course means
controlling the guest environment, and that would mean more interaction with
distro-specific aspects than I personally would like to take on at the moment.
It's not scary when we're doing it for xm-test, because we do control that
environment, but doing it for general guests is more fiddly.  However, I'm
sure somebody somewhere will want to know when the guest is actually booted,
as opposed to merely started, and writing to xenstore seems like a good way to
go about it.

I'd still go with the shell prompt hack though.

Ewan.

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