On Feb 2, 2012, at 4:39 AM, xen-devel-request@lists.xensource.com 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 miss
ing?
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