[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 8/9] xenstore: write xenstore domain data to xenstore
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |