Here are three small patches that I have applied to the Fedora xen builds
and I think are are suitable for xen-4.1.0.
The first patch fixes an anomaly in /etc/xen/scripts/network-route.
Currently this script contains
netdev=${netdev:-eth${vifnum}}
ie. netdev is set to eth${vifnum} by default. Unfortunately vifnum is not
set anywhere in the xen code so the default is actually the broken
"eth".
The patch changes the default to eth0 (which is what the comment at the
top of the file says it should be).
The next patch updates a comment about NetworkManager not supporting
bridging in Fedora 11 to refer instead to Fedora 14.
The final patch solve a build problem in Fedora rawhide, where rpm (4.9.0)
doesn''t automatically supply a "provides" entry for a library
unless it is
executable. This patch makes the libvhd and libblktap library files
executable (and consistent with the other libraries in xen) so that rpm
generates the right "provides" entries and therefore does the right
thing
when resolving package dependencies.
All the patches are
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Michael Young
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Mon, 2011-01-31 at 22:37 +0000, M A Young wrote:> Here are three small patches that I have applied to the Fedora xen builds > and I think are are suitable for xen-4.1.0.Thanks, I general we would prefer separate patches to be submitted separately rather than bundled in a single submission ("hg email" can help with this for large series). In particular having independent changelogs in a form where they can be used directly (e.g. a good firstl ine summary and without references to the "first patch" etc) is much appreciated.> The first patch fixes an anomaly in /etc/xen/scripts/network-route. > Currently this script contains > netdev=${netdev:-eth${vifnum}} > ie. netdev is set to eth${vifnum} by default. Unfortunately vifnum is not > set anywhere in the xen code so the default is actually the broken "eth". > The patch changes the default to eth0 (which is what the comment at the > top of the file says it should be).The comment also refers to an antispoof setting which I don''t see being implemented here. Is that just a wrong comment? (possibly cut and paste error from one of the other network-*)> The next patch updates a comment about NetworkManager not supporting > bridging in Fedora 11 to refer instead to Fedora 14.Was the NetworkManager stuff introduced in 14 and erroneously documented as being in 11, or was it in 11 and worked fine, or has it been continuously broken since F11? IOW should this comment refer to breakage in Fedora 11 thru 14 or something similar?> The final patch solve a build problem in Fedora rawhide, where rpm (4.9.0) > doesn''t automatically supply a "provides" entry for a library unless it is > executable. This patch makes the libvhd and libblktap library files > executable (and consistent with the other libraries in xen) so that rpm > generates the right "provides" entries and therefore does the right thing > when resolving package dependencies.Ick, but apparently normal. Acked-by: Ian Campbell <ian.campbell@citrix.com> Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Tue, 1 Feb 2011, Ian Campbell wrote:> On Mon, 2011-01-31 at 22:37 +0000, M A Young wrote: >> The first patch fixes an anomaly in /etc/xen/scripts/network-route. >> Currently this script contains >> netdev=${netdev:-eth${vifnum}} >> ie. netdev is set to eth${vifnum} by default. Unfortunately vifnum is not >> set anywhere in the xen code so the default is actually the broken "eth". >> The patch changes the default to eth0 (which is what the comment at the >> top of the file says it should be). > > The comment also refers to an antispoof setting which I don''t see being > implemented here. Is that just a wrong comment? (possibly cut and paste > error from one of the other network-*)I think it is wrong (or maybe there was an intention to implement it which never happened. Only the network-bridge has any antispoofing code.>> The next patch updates a comment about NetworkManager not supporting >> bridging in Fedora 11 to refer instead to Fedora 14. > > Was the NetworkManager stuff introduced in 14 and erroneously documented > as being in 11, or was it in 11 and worked fine, or has it been > continuously broken since F11? IOW should this comment refer to breakage > in Fedora 11 thru 14 or something similar?I think it has never worked. Fedora is perhaps mentioned because I think it may have been the first distribution to use NetworkManager. So perhaps the reference to Fedora could be removed altogether or by a more general phrase like "such as in Fedora" . Michael Young _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Campbell writes ("Re: [Xen-devel] Three small patches for
xen-4.1.0-rc"):> On Mon, 2011-01-31 at 22:37 +0000, M A Young wrote:
> > Here are three small patches that I have applied to the Fedora xen
builds
> > and I think are are suitable for xen-4.1.0.
Thanks, I have applied them.
> Thanks, I general we would prefer separate patches to be submitted
> separately rather than bundled in a single submission ("hg email"
can
> help with this for large series).
I agree with Ian''s comments.
> > The next patch updates a comment about NetworkManager not supporting
> > bridging in Fedora 11 to refer instead to Fedora 14.
>
> Was the NetworkManager stuff introduced in 14 and erroneously documented
> as being in 11, or was it in 11 and worked fine, or has it been
> continuously broken since F11? IOW should this comment refer to breakage
> in Fedora 11 thru 14 or something similar?
Perhaps you misread the document ? I don''t think NetworkManager can
set up a bridge at all. So you just have to disable NetworkManager.
I clarified the wording slightly while applying the patch.
> > The final patch solve a build problem in Fedora rawhide, where rpm
(4.9.0)
> > doesn''t automatically supply a "provides" entry for
a library unless it is
> > executable. This patch makes the libvhd and libblktap library files
> > executable (and consistent with the other libraries in xen) so that
rpm
> > generates the right "provides" entries and therefore does
the right thing
> > when resolving package dependencies.
>
> Ick, but apparently normal.
Shared libraries are indeed supposed to be executable. This isn''t the
only thing that can go wrong if they aren''t.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel