[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |