[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Some question to changeset 17962
On Monday, 09 March 2009 at 09:44, Keir Fraser wrote: > On 09/03/2009 09:25, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx> wrote: > > >> For (b), Xen itself has okay semantics -- the most recent > >> caller to set the > >> suspend_evtchn always wins. How tools make use of that policy > >> is up to them > >> works out fine. > > > > Are there any special reason that not the first caller hold it (which is > > more > > nature IMO), and the later caller will failed? > > The only reason I can think is if the xc_save process fails and exit()s and > then we want to continue execution of the domain and maybe try xc_save again > later. Then the first registered evtchn won't be cleaned up and we would > like to overwrite it when we next try xc_save. That was the idea. If tools want to make the first user win, they can agree on a locking strategy between themselves. > Arguably we should make the kernel evtchn driver aware of suspend evtchns > and clean them up on process destruction. Then we could tighten up Xen's > checking. But... It's all kind of a hassle for hardly any reward! Agreed :) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |