From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH 8/9] xenstore: write xenstore domain data to xenstore Date: Thu, 17 Dec 2015 11:08:42 +0100 Message-ID: <567289AA.2010308@suse.com> References: <1449848861-7700-1-git-send-email-jgross@suse.com> <1449848861-7700-9-git-send-email-jgross@suse.com> <1450182380.16856.159.camel@citrix.com> <567008E2.9090606@suse.com> <1450183761.16856.173.camel@citrix.com> <56700D5A.7060008@suse.com> <1450185547.16856.176.camel@citrix.com> <567015FE.6070900@suse.com> <567271A7.7060708@suse.com> <1450346514.4053.94.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1450346514.4053.94.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 , xen-devel@lists.xen.org, ian.jackson@eu.citrix.com, stefano.stabellini@eu.citrix.com, wei.liu2@citrix.com Cc: Daniel De Graaf List-Id: xen-devel@lists.xenproject.org On 17/12/15 11:01, Ian Campbell wrote: > On Thu, 2015-12-17 at 09:26 +0100, Juergen Gross wrote: >> On 15/12/15 14:30, Juergen Gross wrote: >>> On 15/12/15 14:19, Ian Campbell wrote: >>>> On Tue, 2015-12-15 at 13:53 +0100, Juergen Gross wrote: >>>>> >>>>>> mem-set too perhaps? >>>>> >>>>> Without mini-os supporting ballooning or memory hotplug up to now: >>>>> I don't think so. :-) >>>> >>>> Sure, but you'd get strange errors from mem-set rather than a try and >>>> fail, >>>> probably. >>> >>> I'll try it. >> >> I tried both "xl list -l" and "xl mem-set". Seems as if the json object >> would be a good idea. >> >> I guess this will require using libxl and I should move >> init-xenstore-domain to tools/libxl in order to avoid dependency loops. >> >> In the long run I think it would be a good idea to split the libraries >> from the tools using them. So all libraries under tools/libs and the >> programs (xl, init-xenstore-domain, xenstore-ls, ...) under tools/foo. >> Otherwise all programs might tend to migrate to tools/libxl as this >> is the last directory built containing a library. And having to select >> the program's directory by the libraries it is using is a little bit >> strange. >> >> I think this would be a natural next step after Ian's libxc split has >> been applied at least partially by introducing tools/libs. > > Yes, I have a few followup activities planned for after the initial set: > > A. adding libxendevicemodel et al to remove the final unstable APIs from > QEMU. > B. refactoring/splitting tools/libxc so that libxenctrl and libxenguest are > actually separate. Which would probably be an opportune moment to move > to tools/libs/x{c,g} > C. moving libxl to tools/libs/xl and xl to tools/xl (or something) > > (A is independent, but C depends on B for build order reasons) > > However I'm not sure how long it is going to take to get through that list. > In the meantime it does seem that it would make sense to move init- > xenstore-domain alongside xen-init-dom0 in tools/libxl. > > We might even consider merging init-xenstore-domain into xen-init-dom0 as > an optional behaviour. xen-init-dom0 would then be more like xen-init-host > in functionality but renaming would be unnecessary churn IMHO. I'm not > terribly sure this is a good idea... > > You could also consider moving both xen-init-dom0 and init-xenstore-domain > to a new subdirectory of tools (tools/init?) which is built after the libxl > dir. That woudln't conflict with step C above. I like the last variant most. This way there won't be any later adjustments to the libs work needed. What about naming the subdirectory tools/helpers? This would allow to gather more such programs in there without sacrificing the directory name or having to create other directories with just a few tools in there. Juergen