4:21 a.m.
On Mon, Feb 09, 2009 at 12:18:17PM -0500, John Levon wrote:
> > 3. The Sun repository *is* the upstream for xend on Solaris
for a number
> > of reasons:
> >
> > a. The 3.1.x series is only maintained by us, there is no other 3.1 upstream
> >
> > b. The XenSource upstream does not, and cannot, work on Solaris
>
> Are you in essence saying that long term you don't intend to follow the
> new Xen releases, and Solaris XenD should be considered a divergant
> fork long term ?
Certainly not. However, moving to a new Xen version takes a very
long time. The release quality is generally very poor, and combined with
a Linux focus, it often takes weeks of work to move major versions. This
is why we're still on 3.1.4. Practically, we *cannot* follow upstream
directly. We will have enhancements; we'll have fixes; we'll disable
completely broken code like the XenAPI implementation. This doesn't make
us "divergent".
Adding enhancements is what causes the problems & make it divergent,
because the way you add a enhancement for feature XYZ is not guarenteed
to be the way xen-unstable.hg does an enhancement for the same new
feature XYZ. Bug fixes are fine, turning off unneccessary / broken bits
is fine, but adding new features that are not first upstream causes
problems.
> > c. XenSource have no interest in xend at all and it's
effectively
> > unmaintained (with the exception of Novell I think).
>
> While they may not have been doing much active new development work,
> they have still been accepting patches posted on xen-devel from a
> variety of sources, and doing new maintainence releases of the code.
This is very far away from what I consider maintenance.
Likewise, but the fact remains that patches are posted & accepted into
the codebase for issues like the ones being discused with device unplug
of NICs.
> worry about. If it is not sent upstream, and we put the Solaris
speciifc
> code in place, and upstream then implements it in a different way, libvirt
> now has to carry 2 different impls of network unplug code. This is really
> not nice.
It wouldn't be ideal, thankfully I don't expect that to happen. But even
if it did:
72 #ifdef WITH_RHEL5_API
73 #define XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU 0
74 #define XEND_CONFIG_MIN_VERS_PVFB_NEWCONF 2
75 #else
76 #define XEND_CONFIG_MAX_VERS_NET_TYPE_IOEMU 3
77 #define XEND_CONFIG_MIN_VERS_PVFB_NEWCONF 3
78 #endif
This is exactly the same situation: you have a forked version of
upstream that requires special handling.
This is missing the point I have been trying to make. RHEL-5 is using the
old Xen 3.0.3 codebase for XenD. We have added a large number of features
to this over time. *ALL* of these features are things that are already
available in upstream xen-unstable.hg tree. We do not add new features
which are RHEL-5 only because that is not sustainable.
This piece of code from libvirt you quote is not implementing any new
features, it is merely turning on an existing feature. So that something
that is upstream from 3.1.0 or later, is now also used when talking to
Xen 3.0.4. This is why new features should be *backports* of existing
stuff in upstream xen-unstable.hg - it means there only needs to be one
functional implementation of the code in libvirt, which then only has
to be turned on for corect version. Most of the features don't even
need code like the lines you quoted above, becuse they 'just work' when
backported from upstream.
> > 5. This rule further restricts innovation in that XenSource
must agree
> > to any changes. This has a rather obvious chilling effect. The distro
> > type/variant recording changes are a perfect example: this is essential
> > information, and recording it in xend was pre-NAKed by XenSource a long
> > time ago.
>
> IMHO, that's life in open source development. Sometimes things get nack'd
> and have to be implemented in a different manner to be acceptable to all
> members of the upstream community.
There is no different manner without dropping xend altogether. You're
perfectly happy for any stupid decision made by XenSource to negatively
impact the libvirt project? Wow.
I didn't say I would be happy, just that things don't always work out as
expected & sometimes need changing to meet the needs of the broader
community, instead of just my our needs.
> > 6. As a thought experiment: if someone re-wrote xend in C,
what then? Is
> > that upstream, or not? In case it's not clear, all of Sun's Xen
changes
> > are open source and easily available.
>
> It would likely be a totally different product, requiring a from-scratch
> libvirt driver to support it.
Let's see. Your policy has now led us to the situation where to enable
storing of essential debug information, we have to duplicate several
thousand lines of C code.
Or work to get the neccessary feature upstream so it be used by libvirt
and all other users of XenD without everyone having to re-invent it in
their private code trees.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|