New 4.0.2 and 4.1.1 release candidates

New 4.0.2 and 4.1.1 release candidates

[Keir Fraser]

Folks,

New release candidates are tagged in the 4.0 and 4.1 trees:

Tag '4.0.2-rc4' in http://xenbits.xen.org/staging/xen-4.0-testing.hg
 - This is expected to be the final RC for 4.0.2. Please test!

Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
 - Please test, and also suggest further backports for 4.1.1.

 Thanks,
 Keir

Re: New 4.0.2 and 4.1.1 release candidates

[Keir Fraser]

On 21/05/2011 08:04, "Keir Fraser" <keir@xen.org> wrote:

> Folks,
> 
> New release candidates are tagged in the 4.0 and 4.1 trees:
> 
> Tag '4.0.2-rc4' in http://xenbits.xen.org/staging/xen-4.0-testing.hg
>  - This is expected to be the final RC for 4.0.2. Please test!

I have made a new '4.0.2-rc5' tag in the above repository, fixing a couple
of minor issues (including build failure on some older gcc versions). This
is the new final RC tag.

The same patches are also applied to the 4.1-testing repo, and will be
rolled into 4.1.1-rc2 in due course.

 -- Keir

> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
>  - Please test, and also suggest further backports for 4.1.1.
> 
>  Thanks,
>  Keir
> 
> 

Proposal: vif-local

[W. Michael Petullo]

For site-specific reasons, I use the network-route/vif-route scripts. I
have found that we need to maintain a few custom firewall rules in order
to make things operate in an acceptable manner. I'd like to see a place
to put such scripts and any other site-specific setup related to bringing
up a vif. Keeping this separate from vif-route is useful so that the
installed scripts may be kept unmodified.

What I have come up with is vif-local, a script that lives in
/etc/xen/scripts. I modified vif-route to call vif-local right before
it logs "Successful..."

Would it be possible to modify vif-route, vif-bridge, etc. to operate
in this manner? This has been discussed briefly on the list before,
but I had not yet seen a solution.

-- 
Mike

:wq

Re: Proposal: vif-local

[Ian Campbell]

On Thu, 2011-05-05 at 18:15 +0100, W. Michael Petullo wrote:
> For site-specific reasons, I use the network-route/vif-route scripts. I
> have found that we need to maintain a few custom firewall rules in order
> to make things operate in an acceptable manner. I'd like to see a place
> to put such scripts and any other site-specific setup related to bringing
> up a vif. Keeping this separate from vif-route is useful so that the
> installed scripts may be kept unmodified.
> 
> What I have come up with is vif-local, a script that lives in
> /etc/xen/scripts. I modified vif-route to call vif-local right before
> it logs "Successful..."

I think it would be better to be more general and support a vif-post.d
style directory which can contain scripts all of which are called (with
a defined set of paramters/env variables).

Not sure if we want vif-{route,bridge,etc}-post.d or not, perhaps that's
overkill. Using -post.d leaves open the option to add -pre.d in the
future as necessary.

> Would it be possible to modify vif-route, vif-bridge, etc. to operate
> in this manner?

Seems like a reasonable enough idea to me, please send a patch though.

Ian.

Re: Proposal: vif-local

[W. Michael Petullo]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

>> For site-specific reasons, I use the network-route/vif-route scripts. I
>> have found that we need to maintain a few custom firewall rules in order
>> to make things operate in an acceptable manner. I'd like to see a place
>> to put such scripts and any other site-specific setup related to bringing
>> up a vif. Keeping this separate from vif-route is useful so that the
>> installed scripts may be kept unmodified.
>> 
>> What I have come up with is vif-local, a script that lives in
>> /etc/xen/scripts. I modified vif-route to call vif-local right before
>> it logs "Successful..."
 
> I think it would be better to be more general and support a vif-post.d
> style directory which can contain scripts all of which are called (with
> a defined set of paramters/env variables).
 
> Not sure if we want vif-{route,bridge,etc}-post.d or not, perhaps that's
> overkill. Using -post.d leaves open the option to add -pre.d in the
> future as necessary.

I have attached a patch against Xen 4.1.0 that implements a vif-post.d
system. I only support the Linux hotplug case at this point.

-- 
Mike

:wq

[-- Attachment #2: xen-4.1.0-local-vif-scripts.patch --]
[-- Type: text/plain, Size: 2734 bytes --]

diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-bridge xen-4.1.0/tools/hotplug/Linux/vif-bridge
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-bridge	2011-05-06 10:39:15.848610384 -0500
+++ xen-4.1.0/tools/hotplug/Linux/vif-bridge	2011-05-06 10:55:55.347672818 -0500
@@ -105,6 +105,10 @@
     handle_iptable
 fi
 
+for f in /etc/xen/scripts/vif-post.d/*; do
+    [ -x $f ] && $f
+done
+
 log debug "Successful vif-bridge $command for $dev, bridge $bridge."
 if [ "$type_if" = vif -a "$command" = "online" ]
 then
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-nat xen-4.1.0/tools/hotplug/Linux/vif-nat
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-nat	2011-05-06 10:39:15.847610424 -0500
+++ xen-4.1.0/tools/hotplug/Linux/vif-nat	2011-05-06 10:56:10.629062183 -0500
@@ -185,6 +185,10 @@
 
 handle_iptable
 
+for f in /etc/xen/scripts/vif-post.d/*; do
+    [ -x $f ] && $f
+done
+
 log debug "Successful vif-nat $command for ${dev}."
 if [ "$command" = "online" ]
 then
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-post.d/00-vif-local xen-4.1.0/tools/hotplug/Linux/vif-post.d/00-vif-local
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-post.d/00-vif-local	1969-12-31 18:00:00.000000000 -0600
+++ xen-4.1.0/tools/hotplug/Linux/vif-post.d/00-vif-local	2011-05-06 11:54:04.258077228 -0500
@@ -0,0 +1,20 @@
+#============================================================================
+# ${XEN_SCRIPT_DIR}/vif-post.d/00-vif-local
+#
+# Script for performing local configuration of a vif.
+# This script will be sourced by, e.g., vif-bridge after the hotplugging
+# system calls vif-bridge. The script is here and not simply executed as
+# a udev rule because this allows simple access to several environment
+# variables set by the calling vif-* script.
+#
+# Usage:
+# vif-local (add|remove|online|offline)
+#
+# Environment vars:
+# dev         vif interface name (required).
+# main_ip     IP address of Dom0
+# ip          list of IP networks for the vif, space-separated
+# XENBUS_PATH path to this device's details in the XenStore (required).
+#============================================================================
+
+# Place local modifications here.
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-route xen-4.1.0/tools/hotplug/Linux/vif-route
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-route	2011-05-06 10:39:15.845610504 -0500
+++ xen-4.1.0/tools/hotplug/Linux/vif-route	2011-05-06 12:00:06.029751382 -0500
@@ -49,6 +49,10 @@
 
 handle_iptable
 
+for f in /etc/xen/scripts/vif-post.d/*; do
+    [ -x $f ] && . $f
+done
+
 log debug "Successful vif-route ${command} for ${dev}."
 if [ "${command}" = "online" ]
 then

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: Proposal: vif-local

[Ian Campbell]

On Fri, 2011-05-06 at 18:06 +0100, W. Michael Petullo wrote:
> >> For site-specific reasons, I use the network-route/vif-route scripts. I
> >> have found that we need to maintain a few custom firewall rules in order
> >> to make things operate in an acceptable manner. I'd like to see a place
> >> to put such scripts and any other site-specific setup related to bringing
> >> up a vif. Keeping this separate from vif-route is useful so that the
> >> installed scripts may be kept unmodified.
> >> 
> >> What I have come up with is vif-local, a script that lives in
> >> /etc/xen/scripts. I modified vif-route to call vif-local right before
> >> it logs "Successful..."
>  
> > I think it would be better to be more general and support a vif-post.d
> > style directory which can contain scripts all of which are called (with
> > a defined set of paramters/env variables).
>  
> > Not sure if we want vif-{route,bridge,etc}-post.d or not, perhaps that's
> > overkill. Using -post.d leaves open the option to add -pre.d in the
> > future as necessary.
> 
> I have attached a patch against Xen 4.1.0 that implements a vif-post.d
> system. I only support the Linux hotplug case at this point.

Thanks. I've got a few comments.

The header of "${XEN_SCRIPT_DIR}/vif-post.d/00-vif-local" describes a
command line parameter "(add|remove|online|offline)" but none of the
invocations actually pass one.

I think it would be better to encapsulate the functionality in a
"call_hooks <devtype> <hook> <other args...>" function in
xen-hotplug-common.sh, calling it as "call_hooks vif post ..." rather
than open coding that loop everywhere.

I think generally it is a good idea to have an explicit suffix (e.g.
".hook") for this sort of thing since then you can use *.hook to get the
list of files which saves manually filtering out *~ *.rpmsave *.dpkg-bak
*.disabled-by-admin *.some-random-suffix-intended-to-disable-the-script
etc.

You probably want to quote $f in case some nutter uses a space in the
hook filename.

You don't actually install 00-vif-local but I think that's a good thing
since the default is an empty script so we save a fork/exec by not
running it.

Lastly we need a Signed-off-by per the DCO (section 11 of
http://lwn.net/Articles/139918/) as well as a suitable changelog message
before we can apply any patch.

Thanks,
Ian.

Re: Proposal: vif-local

[W. Michael Petullo]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

>> I have attached a patch against Xen 4.1.0 that implements a vif-post.d
>> system. I only support the Linux hotplug case at this point.
 
> The header of "${XEN_SCRIPT_DIR}/vif-post.d/00-vif-local" describes a
> command line parameter "(add|remove|online|offline)" but none of the
> invocations actually pass one.

Since the hooks are now sourced they no longer take parameters. It is,
in fact, a shell variable and I have updated the comments.

> I think it would be better to encapsulate the functionality in a
> "call_hooks <devtype> <hook> <other args...>" function in
> xen-hotplug-common.sh, calling it as "call_hooks vif post ..." rather
> than open coding that loop everywhere.

Good idea. Implemented.
 
> I think generally it is a good idea to have an explicit suffix (e.g.
> ".hook") for this sort of thing since then you can use *.hook to get the
> list of files which saves manually filtering out *~ *.rpmsave *.dpkg-bak
> *.disabled-by-admin *.some-random-suffix-intended-to-disable-the-script
> etc.

Implemented.
 
> You probably want to quote $f in case some nutter uses a space in the
> hook filename.

Implemented.
 
> You don't actually install 00-vif-local but I think that's a good thing
> since the default is an empty script so we save a fork/exec by not
> running it.

Good.
 
> Lastly we need a Signed-off-by per the DCO (section 11 of
> http://lwn.net/Articles/139918/) as well as a suitable changelog message
> before we can apply any patch.

Please see the attached patch.

Allow for site-specific hooks that will be executed after Xen initializes
a vif. This allows an administrator to specify custom firewall rules or
other special configuration parameters.

Signed-off-by: W. Michael Petullo <mike@flyn.org>

-- 
Mike

:wq

[-- Attachment #2: xen-4.1.0-local-vif-scripts-1.patch --]
[-- Type: text/plain, Size: 3256 bytes --]

diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-bridge xen-4.1.0/tools/hotplug/Linux/vif-bridge
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-bridge	2011-05-06 10:39:15.848610384 -0500
+++ xen-4.1.0/tools/hotplug/Linux/vif-bridge	2011-05-09 11:47:03.247718082 -0500
@@ -105,6 +105,8 @@
     handle_iptable
 fi
 
+call_hooks vif post
+
 log debug "Successful vif-bridge $command for $dev, bridge $bridge."
 if [ "$type_if" = vif -a "$command" = "online" ]
 then
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-nat xen-4.1.0/tools/hotplug/Linux/vif-nat
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-nat	2011-05-06 10:39:15.847610424 -0500
+++ xen-4.1.0/tools/hotplug/Linux/vif-nat	2011-05-09 11:47:11.815394984 -0500
@@ -185,6 +185,8 @@
 
 handle_iptable
 
+call_hooks vif post
+
 log debug "Successful vif-nat $command for ${dev}."
 if [ "$command" = "online" ]
 then
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-post.d/00-vif-local.hook xen-4.1.0/tools/hotplug/Linux/vif-post.d/00-vif-local.hook
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-post.d/00-vif-local.hook	1969-12-31 18:00:00.000000000 -0600
+++ xen-4.1.0/tools/hotplug/Linux/vif-post.d/00-vif-local.hook	2011-05-09 11:21:12.438113611 -0500
@@ -0,0 +1,18 @@
+#============================================================================
+# ${XEN_SCRIPT_DIR}/vif-post.d/00-vif-local.hook
+#
+# Script for performing local configuration of a vif.
+# This script will be sourced by, e.g., vif-bridge after the hotplugging
+# system calls vif-bridge. The script is here and not simply executed as
+# a udev rule because this allows simple access to several environment
+# variables set by the calling vif-* script.
+#
+# Environment vars:
+# command     (add|remove|online|offline)
+# dev         vif interface name (required).
+# main_ip     IP address of Dom0
+# ip          list of IP networks for the vif, space-separated
+# XENBUS_PATH path to this device's details in the XenStore (required).
+#============================================================================
+
+# Place local modifications here.
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/vif-route xen-4.1.0/tools/hotplug/Linux/vif-route
--- xen-4.1.0-vanilla/tools/hotplug/Linux/vif-route	2011-05-06 10:39:15.845610504 -0500
+++ xen-4.1.0/tools/hotplug/Linux/vif-route	2011-05-09 11:46:57.408939221 -0500
@@ -49,6 +49,8 @@
 
 handle_iptable
 
+call_hooks vif post
+
 log debug "Successful vif-route ${command} for ${dev}."
 if [ "${command}" = "online" ]
 then
diff -u --recursive --new-file xen-4.1.0-vanilla/tools/hotplug/Linux/xen-hotplug-common.sh xen-4.1.0/tools/hotplug/Linux/xen-hotplug-common.sh
--- xen-4.1.0-vanilla/tools/hotplug/Linux/xen-hotplug-common.sh	2011-05-06 10:39:15.847610424 -0500
+++ xen-4.1.0/tools/hotplug/Linux/xen-hotplug-common.sh	2011-05-09 11:43:09.239663639 -0500
@@ -99,4 +99,15 @@
   _xenstore_write "$@" || fatal "Writing $@ to xenstore failed."
 }
 
+##
+# call_hooks <devtype> <hook>
+#
+# Execute each hook in the <hook> directory.
+#
+call_hooks() {
+  for f in /etc/xen/scripts/${1}-${2}.d/*.hook; do
+    [ -x "$f" ] && . "$f"
+  done
+}
+
 log debug "$@" "XENBUS_PATH=$XENBUS_PATH"

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: Proposal: vif-local

[Ian Campbell]

On Mon, 2011-05-09 at 18:10 +0100, W. Michael Petullo wrote:
> > Lastly we need a Signed-off-by per the DCO (section 11 of
> > http://lwn.net/Articles/139918/) as well as a suitable changelog message
> > before we can apply any patch.
> 
> Please see the attached patch.
> 
> Allow for site-specific hooks that will be executed after Xen initializes
> a vif. This allows an administrator to specify custom firewall rules or
> other special configuration parameters.
> 
> Signed-off-by: W. Michael Petullo <mike@flyn.org>

This is against 4.1? can you check that it applies to xen-unstable.hg
please, other than that:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

Cheers,
Ian.

Re: Proposal: vif-local

[W. Michael Petullo]

>>> Lastly we need a Signed-off-by per the DCO (section 11 of
>>> http://lwn.net/Articles/139918/) as well as a suitable changelog message
>>> before we can apply any patch.
 
>> Please see the attached patch.

>> Allow for site-specific hooks that will be executed after Xen initializes
>> a vif. This allows an administrator to specify custom firewall rules or
>> other special configuration parameters.
>> 
>> Signed-off-by: W. Michael Petullo <mike@flyn.org>
 
> This is against 4.1? can you check that it applies to xen-unstable.hg
> please, other than that:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

I pulled xen-unstable.hg from Mercurial and the patch applied cleanly. The
modified scripts were identical to those resulting from applying the
patch against 4.1.0.

-- 
Mike

:wq

Re: Proposal: vif-local

[Ian Campbell]

On Tue, 2011-05-10 at 17:06 +0100, W. Michael Petullo wrote:
> >>> Lastly we need a Signed-off-by per the DCO (section 11 of
> >>> http://lwn.net/Articles/139918/) as well as a suitable changelog message
> >>> before we can apply any patch.
>  
> >> Please see the attached patch.
> 
> >> Allow for site-specific hooks that will be executed after Xen initializes
> >> a vif. This allows an administrator to specify custom firewall rules or
> >> other special configuration parameters.
> >> 
> >> Signed-off-by: W. Michael Petullo <mike@flyn.org>
>  
> > This is against 4.1? can you check that it applies to xen-unstable.hg
> > please, other than that:
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> I pulled xen-unstable.hg from Mercurial and the patch applied cleanly. The
> modified scripts were identical to those resulting from applying the
> patch against 4.1.0.

Great, thanks for checking. My Acked-by stands...

Ian.

Re: Re: New 4.0.2 and 4.1.1 release candidates

[W. Michael Petullo]

>> New release candidates are tagged in the 4.0 and 4.1 trees:
>> 
>> Tag '4.0.2-rc4' in http://xenbits.xen.org/staging/xen-4.0-testing.hg
>>  - This is expected to be the final RC for 4.0.2. Please test!
 
> I have made a new '4.0.2-rc5' tag in the above repository, fixing a couple
> of minor issues (including build failure on some older gcc versions). This
> is the new final RC tag.
> 
> The same patches are also applied to the 4.1-testing repo, and will be
> rolled into 4.1.1-rc2 in due course.

Is it too late to merge the patch discussed at

	http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00306.html

?

In the email thread you will find the patch and an ack.

-- 
Mike

:wq

Re: Re: New 4.0.2 and 4.1.1 release candidates

[Keir Fraser]

On 24/05/2011 15:17, "W. Michael Petullo" <mike@flyn.org> wrote:

>>> New release candidates are tagged in the 4.0 and 4.1 trees:
>>> 
>>> Tag '4.0.2-rc4' in http://xenbits.xen.org/staging/xen-4.0-testing.hg
>>>  - This is expected to be the final RC for 4.0.2. Please test!
>  
>> I have made a new '4.0.2-rc5' tag in the above repository, fixing a couple
>> of minor issues (including build failure on some older gcc versions). This
>> is the new final RC tag.
>> 
>> The same patches are also applied to the 4.1-testing repo, and will be
>> rolled into 4.1.1-rc2 in due course.
> 
> Is it too late to merge the patch discussed at
> 
> http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00306.html
> 
> ?
> 
> In the email thread you will find the patch and an ack.

I only backport toolstack patches that I'm requested to by a toolstack
maintainer. Cc'ing Ian Jackson.

(And it's not too late for 4.1.1, assuming the backport is acceptable.)

 -- Keir

Re: Proposal: vif-local [and 1 more messages]

[Ian Jackson]

W. Michael Petullo writes ("Re: [Xen-devel] Re: New 4.0.2 and 4.1.1 release candidates"):
> Is it too late to merge the patch discussed at
>   http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00306.html

We don't generally apply patches directly to the stable trees (4.0 and
4.1, at the moment).  We like them to come through xen-unstable first.

When you submitted your patch, you got this reply:

Ian Campbell writes ("Re: [Xen-devel] Proposal: vif-local"):
> On Mon, 2011-05-09 at 18:10 +0100, W. Michael Petullo wrote:
> > Allow for site-specific hooks that will be executed after Xen initializes
> > a vif. This allows an administrator to specify custom firewall rules or
> > other special configuration parameters.
> > 
> > Signed-off-by: W. Michael Petullo <mike@flyn.org>
> 
> This is against 4.1? can you check that it applies to xen-unstable.hg
> please, other than that:
> 
> Acked-by: Ian Campbell <ian.campbell@citrix.com>

Can you confirm that your patch applies and works correctly against
xen-unstable.hg ?

Thanks,
Ian.

Re: Proposal: vif-local [and 1 more messages]

[Ian Campbell]

On Tue, 2011-05-24 at 18:31 +0100, Ian Jackson wrote:
> W. Michael Petullo writes ("Re: [Xen-devel] Re: New 4.0.2 and 4.1.1 release candidates"):
> > Is it too late to merge the patch discussed at
> >   http://lists.xensource.com/archives/html/xen-devel/2011-05/msg00306.html
> 
> We don't generally apply patches directly to the stable trees (4.0 and
> 4.1, at the moment).  We like them to come through xen-unstable first.
> 
> When you submitted your patch, you got this reply:
> 
> Ian Campbell writes ("Re: [Xen-devel] Proposal: vif-local"):
> > On Mon, 2011-05-09 at 18:10 +0100, W. Michael Petullo wrote:
> > > Allow for site-specific hooks that will be executed after Xen initializes
> > > a vif. This allows an administrator to specify custom firewall rules or
> > > other special configuration parameters.
> > > 
> > > Signed-off-by: W. Michael Petullo <mike@flyn.org>
> > 
> > This is against 4.1? can you check that it applies to xen-unstable.hg
> > please, other than that:
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Can you confirm that your patch applies and works correctly against
> xen-unstable.hg ?

Michael replied to this mail in <20110510160631.GA17482@imp.local>:

> I pulled xen-unstable.hg from Mercurial and the patch applied cleanly.
> The modified scripts were identical to those resulting from applying
> the patch against 4.1.0.

Ian.

Re: Proposal: vif-local [and 1 more messages]

[Ian Jackson]

Ian Campbell writes ("Re: [Xen-devel] Proposal: vif-local [and 1 more messages]"):
> On Tue, 2011-05-24 at 18:31 +0100, Ian Jackson wrote:
> > Can you confirm that your patch applies and works correctly against
> > xen-unstable.hg ?
> 
> Michael replied to this mail in <20110510160631.GA17482@imp.local>:

I don't know how I overlooked that.  Sorry.  I have applied the patch
to xen-unstable.

Ian.

Re: New 4.0.2 and 4.1.1 release candidates

[Olaf Hering]

On Sat, May 21, Keir Fraser wrote:

> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
>  - Please test, and also suggest further backports for 4.1.1.

Keir,

what about all the changes made to xen/common/trace.c up to now?

Olaf

Re: New 4.0.2 and 4.1.1 release candidates

[Keir Fraser]

On 24/05/2011 17:13, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Sat, May 21, Keir Fraser wrote:
> 
>> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
>>  - Please test, and also suggest further backports for 4.1.1.
> 
> Keir,
> 
> what about all the changes made to xen/common/trace.c up to now?

There are *loads* of them. I don't think so, presumably it's not really all
bug fixes. It's somewhat up to George however.

 -- Keir

> Olaf

Re: New 4.0.2 and 4.1.1 release candidates

[Olaf Hering]

On Tue, May 24, Keir Fraser wrote:

> On 24/05/2011 17:13, "Olaf Hering" <olaf@aepfle.de> wrote:
> 
> > On Sat, May 21, Keir Fraser wrote:
> > 
> >> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
> >>  - Please test, and also suggest further backports for 4.1.1.
> > 
> > Keir,
> > 
> > what about all the changes made to xen/common/trace.c up to now?
> 
> There are *loads* of them. I don't think so, presumably it's not really all
> bug fixes. It's somewhat up to George however.

I think 23173 is a bugfix, but I have never used cpu hotplug.

Olaf

Re: New 4.0.2 and 4.1.1 release candidates

[Keir Fraser]

On 24/05/2011 19:25, "Olaf Hering" <olaf@aepfle.de> wrote:

> On Tue, May 24, Keir Fraser wrote:
> 
>> On 24/05/2011 17:13, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Sat, May 21, Keir Fraser wrote:
>>> 
>>>> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
>>>>  - Please test, and also suggest further backports for 4.1.1.
>>> 
>>> Keir,
>>> 
>>> what about all the changes made to xen/common/trace.c up to now?
>> 
>> There are *loads* of them. I don't think so, presumably it's not really all
>> bug fixes. It's somewhat up to George however.
> 
> I think 23173 is a bugfix, but I have never used cpu hotplug.

It fixes a bug introduced by some other post-4.1 patch. The bug is not in
4.1.

 -- Keir

> Olaf

Re: New 4.0.2 and 4.1.1 release candidates

[George Dunlap]

On Tue, May 24, 2011 at 6:58 PM, Keir Fraser <keir.xen@gmail.com> wrote:
> On 24/05/2011 17:13, "Olaf Hering" <olaf@aepfle.de> wrote:
>
>> On Sat, May 21, Keir Fraser wrote:
>>
>>> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
>>>  - Please test, and also suggest further backports for 4.1.1.
>>
>> Keir,
>>
>> what about all the changes made to xen/common/trace.c up to now?
>
> There are *loads* of them. I don't think so, presumably it's not really all
> bug fixes. It's somewhat up to George however.

It looks like 23091:67632e5cf652 and 23128:4a335f1000ea are fixes to
code changed in 23050:4ebba54b666f, is that correct?  I don't see
anything else that's a candidate for backporting.

 -George

Re: New 4.0.2 and 4.1.1 release candidates

[Keir Fraser]

On 26/05/2011 09:36, "George Dunlap" <dunlapg@umich.edu> wrote:

> On Tue, May 24, 2011 at 6:58 PM, Keir Fraser <keir.xen@gmail.com> wrote:
>> On 24/05/2011 17:13, "Olaf Hering" <olaf@aepfle.de> wrote:
>> 
>>> On Sat, May 21, Keir Fraser wrote:
>>> 
>>>> Tag '4.1.1-rc1' in http://xenbits.xen.org/staging/xen-4.1-testing.hg
>>>>  - Please test, and also suggest further backports for 4.1.1.
>>> 
>>> Keir,
>>> 
>>> what about all the changes made to xen/common/trace.c up to now?
>> 
>> There are *loads* of them. I don't think so, presumably it's not really all
>> bug fixes. It's somewhat up to George however.
> 
> It looks like 23091:67632e5cf652 and 23128:4a335f1000ea are fixes to
> code changed in 23050:4ebba54b666f, is that correct?  I don't see
> anything else that's a candidate for backporting.

Yes, my understanding is that all subsequent changes and fixes to trace.c in
xen-unstable stem from c/s 23050, which is a big feature patch likely
unsuitable for backport to 4.1. So we should put this to bed and backport
nothing.

 -- Keir

>  -George