Re: [PATCH v2 03/13] libxl: provide a function to retrieve the xenstore domain id

[Juergen Gross <jgross@suse.com>]

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