[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [patch 5/6] frontend device shutdown
Keir Fraser wrote: > I think the problem here is that the xenbus state machine does not > distinguish who is driving a sequence of state changes. One of the problems, yes. The most tricky one is the handover of the frontend device from one kernel to the next (same issues will come up for some minios+grub based bootloader if someone goes creating one ...). The prerequisites we have are: * We _must not_ break old domUs. * I'd like to be able to boot old domU kernels via kexec, so the post-kexec environment should be identical to what the domain builder creates today. The backward compatibility issue makes it very tricky to add new states, such as "Disconnecting" for example. Todays domU kernels expect to find the frontend device state in Initializing and the backend device state in Initializing or InitWait. That are the main reasons I went the route to switch back to Initializing state in the frontend, and I see no easy way around that. The backend responds by cleaning up and preparing for the frontend going to "Connected" state again, and sets its own state to "InitWait" to signal that to the frontend. That is a perfectly fine environment for the new kernel. Unfortunaly the old kernel's frontend reacts on that state change too, which did lead to the introduction of the shutdown_in_progress flag in xenbus_device to avoid that. I hope that are all gotchas I ran into (thats the problem with two weeks vacation between writing code and submitting patches, you forget some of the tricky details ...). cheers, Gerd -- Gerd Hoffmann <kraxel@xxxxxxx> http://www.suse.de/~kraxel/julika-dora.jpeg _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |