From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id Date: Thu, 7 Jan 2016 12:21:45 +0100 Message-ID: <568E4A49.60703@suse.com> References: <1450444471-6454-1-git-send-email-jgross@suse.com> <1450444471-6454-4-git-send-email-jgross@suse.com> <56740FC2.4030504@citrix.com> <567413E8.3010301@suse.com> <1452095954.21055.98.camel@citrix.com> <568DF99E.9010503@suse.com> <1452161493.21055.157.camel@citrix.com> <568E41AB.5050004@suse.com> <1452164121.21055.186.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1452164121.21055.186.camel@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Andrew Cooper , xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com, dgdegra@tycho.nsa.gov List-Id: xen-devel@lists.xenproject.org On 07/01/16 11:55, Ian Campbell wrote: > On Thu, 2016-01-07 at 11:44 +0100, Juergen Gross wrote: >>>> IMO the generic concept you are asking for should be added in a >>>> separate patch handling stopping (and possibly rebooting) driver >>>> domains in a clean way. >>> >>> Since libxl has a stable API once we add something we need to continue >>> supporting it, so we cannot (easily/cleanly) switch an xs specific >>> scheme >>> into a generic one later. That argues then for supporting the XS case >>> via >>> the generic mechanism now, even if we don't implement the other cases. >> >> I can't see a scenario where the xenstore domain would have to be >> stopped by dom0. Once you do it you'll never be able to connect to >> it again without changing the xenbus driver interface, too. It is >> the same reason why xenstored can't be restarted. >> >> Driver domains are different and I think the interface to query a >> domain whether it is a driver domain or whether it might survive a >> dom0 reboot should be based on xenstore. >> >> So a xenstore domain would always need special handling. > > If there is really _never_ any reason to stop the xs domain then I think at > the libxl API level a class of "never stop" domains would be better than > special casing the xs, even if it turns out the only member of the set is > xs at least we've given ourselves wriggle room if something else comes up > in the future. Okay, so this would translate to either: - add a "never stop" flag to libxl_dominfo (can I do this without breaking the API?) - add a new call interface to either check a single domain to be of the "never stop" class or to return a list of those domains. Preferences? Juergen