Re: [Xen-devel] Xen-devel Digest, Vol 84, Issue 38 - autoconf

[Qrux <qrux.qed@xxxxxxxxx>]

On Feb 2, 2012, at 4:39 AM, xen-devel-request@xxxxxxxxxxxxxxxxxxx wrote:

> Today's Topics:
> 
>   1. Re: [PATCH v4] build: add autoconf to replace custom checks
>      in tools/check (Ian Campbell)

Howdy all,

I'm new to the Xen-Devel list, but I've been using Xen for many years.  Xen is 
a great product, and the collective work you've done has been amazing.  I'm 
excited to see a digest post about moving toward autoconf.  Along those lines, 
I have some input for the build process.  There may be bits that are factually 
wrong; and I'd be happy to stand corrected; however, much of what follows are 
perceptions, which I think could be equally important to the long term success 
of Xen, especially with competitors like KVM.

(I sent this to Ian, and he felt it belonged on the list.)

* * *

I've been using Xen on openSUSE for a long time.  My use case for Xen:

        * Pure 64-bit dom0.
        * Pure 64-bit pure PV domUs.
        * No need for X11--CLI management is fine.
        * No need for VGA-passthrough (ssh is enough).
        * No need for any fancy device-handling or HVM support.

After two ugly hacks, (but a "working" hypervisor, dom0, and domU), my sense of 
the Xen build process is, basically, that it tries to build too much stuff.  
For example, the Hypervisor is separated from the tools.  Good.  But, all the 
tools are bunched together, including xl, xm, firmware, PVHVM stuff.  Bad?  
That seems like a horrid lack of separation.  And, my perception is that 
configuration is harder--or perhaps scarier--that it needs to be, with a 
top-level Config.mk containing variables (which are easy enough to toggle) but 
also tons of logic (which makes me not want to work in that file).

Long story short, what I thought was the most "baseline" case (64-bit dom0, 
64-bit domUs, pure PV, no HVM or PVHVM, no X11, and just wanting the xl tools) 
turned out to be much uglier than it seems was necessary.  As you move toward 
autoconf, I would hope that there will be (somewhat comprehensible) switches 
like:

        --with-X11-tools
        --without-X11-tools
        --with-xm
        --without-xm
        --no-32-bit-support

I propose that the configure process tries to separate as much as possible; 
e.g., keep all the tools apart from each other, and separate out mandatory 
(e.g., xl) from not (X11 stuff) and "possibly necessary based on your use case" 
(e.g., tools/firmware for HVM guests).

I also propose that when Xen is to be built from source, the build system 
should aggressively prune non-critical items (i.e., not the hypervisor or 
xl/xm); i.e., those parts should not be included unless specified (e.g., 
tools/firmware).  Whatever is in the default build should allow a user to run 
SOME specific baseline dom0/domU configuration (I would think the PV default is 
the least dependent mode), but leave everything else to the builder.

Why do I think that?  Because of the adage:

        "Make it easy to do what's easy, and possible to do what's hard."

Integration is the value-add provided by commercial distros. They have the 
resources to put full-time staff onto issues, even if they're simply liaising 
with the Xen developers.  But, small-system-builders--many of which provided 
the critical mass for Xen to come up--can get bogged down in these complex 
dependencies.

Sure, branding is important from Xen's marketing perspective; it's nice to be 
able to release a fully-functional product that does everything it says "on the 
box".  But, again, I think that's something that the commercial groups are 
doing fine with.  They can release their implementation that supports every 
bell and whistle.  But, I would still submit that folks who compile Xen 
themselves would like a slightly less "hairy" experience, and could live 
without certain features.  They would also have commercial distros to fall back 
on, or let other non-commercial projects (NetBSD, Ubuntu, LFS) catch up, and 
inform them.  So, since that's already the case, shouldn't the default Xen 
build require as little as possible--but be aggressive in building a usable 
target, even if some features are missing?

TL;DR--

        * Define "baseline" functionality with a minimum set of dependencies.

        * Have autoconf fail if those deps aren't met.

        * If those deps *are* met (kernel settings, compiler, etc)...

        * ...be able to build a "baseline" that allows Xen to function.

        * Add other tools (with external dependencies) purely as opt-ins.

I think that would follow the principle of least-surprise, in a configuration 
sense.  Other large systems, like Apache or PHP or Postgres, seem to try to 
detect features, and incorporate them if found.  But, if those features don't 
exist, they don't hamper the parts that can be properly built.  I think those 
systems aggressively try to successfully build a target.  And, the default 
configuration is obviously a subset of all the available features, which are 
left to the builder's choice.  There *is* a sense of what a "baseline" build 
for those systems is like, even if it's a de-facto result of C;M;MI.  I believe 
that my system (LFS) is as bare a system as one can reasonably have (that's not 
embedded).  I'd be happy to help test the build.

Again, I respect all the hard and wonderful work that's been done.  Yet, I 
think these are important issues that may influence the future of Xen's 
success.  KVM is a gnarly competitor, and it seems to build with relative ease 
(granted, it's a Linux-host-only solution).  Sure, Xen is a Type-1 hypervisor, 
is mature, and has a lot of users.  But, its perceived complexity seems to be 
many many orders of magnitude higher that the perceived benefit.  That doesn't 
seem good for Xen's brand...

I hope this will spark some dialogue, and I'm happy to participate further 
either privately or on the lists.

        Q




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel