[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xenstore domain

On 08/12/15 17:34, Andrew Cooper wrote:
> On 08/12/15 16:02, Juergen Gross wrote:
>> On 08/12/15 16:04, Andrew Cooper wrote:
>>> On 08/12/15 14:44, Juergen Gross wrote:
>>>> I'm just playing a little bit with xenstore in an own domain.
>>>> I've come across some questions I'd like to have some answers to before
>>>> presenting official patches to make this an easy configurable option:
>>>> a) As this would need a boot time configuration item I'd like to add
>>>>    e.g. /etc/xen/server.conf where such global configuration options
>>>>    could be set via directives. Is this generally okay? If yes, which
>>>>    format? Easiest way would be entries like
>>>>    VAR=value
>>>>    which can be either sourced in from shell scripts or can easily be
>>>>    parsed in all programming languages. What are the preferences here?
>>> Any configuration like this going to be toolstack-specific.  I would
>>> recommend against using a name as generic as that.
>>> /etc/xl.conf already exists, which IMO would be the natural place for
>>> this to live, but it isn't parseable by shell, because of vif notation.
>> OTOH that file wouldn't be just for xl. It would be consumed by e.g.
>> xencommons. Other configuration options I'd plan to add would be
>> driver domains dedicated to specific interface cards.
> It is still logically part of the "xl toolstack infrastructure", but I
> accept your point.  The current xl.conf is all about how to create
> domains in general, rather than specifically "how I would like my system
> configured when starting up".
>>> One option might be to alter xl.conf to be compatible with shell
>>> parsing.  It wouldn't be complicated (even in upgrade situations), and
>>> would offer rather more flexibility.
>> Shell parsing could be even handled via a rather simple filter, I guess.
>>>> b) Today init-xenstore-domain will require flask to be enabled. An
>>>>    alternative would be to add a new domain creation flag to allow the
>>>>    domains with that flag set calling xc_domain_getinfo(). Thoughts?
>>> Which flag?
>> A new domcr_flag.
> Indicating what, precisely?

What I need is the capability to do the XEN_DOMCTL_getdomaininfo
hypercall from the xenstore domain. Question is whether it's better
to tie this special capability to the flag or to name it "is_xenstore".

Thinking more about it, especially regarding a possible enhancement
allowing Dom0 to reboot, I think the is_xenstore variant would be
better. This would allow to look whether a xenstore domain is already
running and connect to that rather than try to start a new one.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.