[Pkg-xen-devel] My Xen package plans/thoughts/ideas for Jessie

Ian Campbell ijc at hellion.org.uk
Fri Oct 5 11:51:21 UTC 2012


On Fri, 2012-10-05 at 13:04 +0200, Bastian Blank wrote:
> On Fri, Oct 05, 2012 at 11:49:48AM +0100, Ian Campbell wrote:
> > This allows people to only install the toolstack they are interested in
> > using, helps us transition from xend->xl and to deprecate xend when the
> > time comes. I suspect it could also be used to simplify the $TOOLSTACK
> > stuff via /etc/defaults/xen.
> 
> What are the advantages for the users and the maintainers?

Mostly the ability to not install unwanted cruft (like xend).

It might also be possible to make a more sensible automatic
determination for $TOOLSTACK when only one is installed, which removes
the need for people to manually edit /etc/defaults/xen.

> > It's an open question whether the xen-toolstack-*-X.Y packages should
> > also conflict/replace xen-toolstack-X.Y. It seems like being able to
> > install e.g. xl and xcp-xapi simultaneously might be somewhat useful for
> > debugging and things like that.
> 
> Does this work?

I've not tried it my self but apparently it does at least for debugging
purposes i.e. something weird happens using xapi and you want to try and
narrow it down by using xl.

I think the basic prerequisite for this to work is that neither
toolstack ever touches domains which it did not create, which I think
holds for both xl and xapi.

> > There's probably scope for going even more fine grained splitting e.g.
> > put the language bindings in their own packages and splitting up the
> > various classes of utils a bit but I think that would be taking things
> > too far.
> 
> Adding new packages highers the costs for all users. So adding packages
> just for fun is not the way to go.

Agreed.

> 
> >       * Enable ocaml xenstored (oxenstored). Not sure if we do this
> >         already done in the 4.2 packaging. I'd like to make it the
> >         default if possible. Not sure if this is worth dual packages
> >         allowing users to choose or if we should just pick one.
> 
> Unlikely, unless it just does it without me noticing it.

There's a pretty good chance it is built but not installed I think since
the build deps do include ocamlc these days.

> >       * Package libxenlight so others can link against it, at least
> >         libvirt and xcp-xapi (at some point in the future) are going to
> >         want to do this.
> 
> With the lib in the current state? Not until the error checking stuff is
> actually worked out. Memory management routing must never call exit if
> they can't make sure it does not break stuff.

Are you thinking of the MUST_CHECK stuff? Because that's xl not libxl.

The behaviour of libxl when a memory allocation fails was a deliberate
decision made after consulting all the main users (xl, xapi, libvirt).

Ian.
-- 
Ian Campbell
Current Noise: Bloodbath - Outnumbering The Day

Sorry, no fortune this time.




More information about the Pkg-xen-devel mailing list