Re: [PATCH 8/9] xenstore: write xenstore domain data to xenstore

[Ian Campbell <ian.campbell@citrix.com>]

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.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel