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

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

On Thu, 2015-12-17 at 11:08 +0100, Juergen Gross wrote:
> 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.

I don't really mind, although directory names aren't exactly in short
supply IMHO and git mv is always an option later. Do as you like I think.

Ian.


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