[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xm-test domain creation delay
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |