From: Gerd Hoffmann <kraxel@suse.de>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Xen devel list <xen-devel@lists.xensource.com>,
Ewan Mellor <ewan@xensource.com>
Subject: Re: [patch 5/6] frontend device shutdown
Date: Tue, 22 Aug 2006 10:04:33 +0200 [thread overview]
Message-ID: <44EABA91.8050705@suse.de> (raw)
In-Reply-To: <C10F99C9.1244%Keir.Fraser@cl.cam.ac.uk>
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@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg
next prev parent reply other threads:[~2006-08-22 8:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-17 14:03 [patch 5/6] frontend device shutdown Gerd Hoffmann
2006-08-19 12:25 ` Keir Fraser
2006-08-19 12:29 ` Keir Fraser
2006-08-21 14:11 ` Gerd Hoffmann
2006-08-21 16:11 ` Keir Fraser
2006-08-22 8:04 ` Gerd Hoffmann [this message]
2006-08-22 8:30 ` Keir Fraser
2006-08-22 8:40 ` Keir Fraser
2006-08-22 9:12 ` Gerd Hoffmann
2006-08-22 10:22 ` Gerd Hoffmann
2006-08-19 12:52 ` Keir Fraser
2006-08-21 6:48 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44EABA91.8050705@suse.de \
--to=kraxel@suse.de \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=ewan@xensource.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.