[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. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |