[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.


Xen-devel mailing list



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