Re: [Xen-devel] [PATCH] [RFC] Fix RegEx Issues with xendomains for both SXP and JSON outputs of lx list -l

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2013-06-25 at 11:56 +0100, Ian Murray wrote:
> 
> 
> 
> ----- Original Message -----
> > From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
> > To: Ian Murray <murrayie@xxxxxxxxxxx>
> > Cc: "xen-devel@xxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxx>; David Sutton 
> > <kantras@xxxxxxxxx>; Joshua Tuttle <jtuttle@xxxxxxxxx>; George Dunlap 
> > <george.dunlap@xxxxxxxxxxxxx>; Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
> > Sent: Tuesday, 25 June 2013, 10:40
> > Subject: Re: [PATCH] [RFC] Fix RegEx Issues with xendomains for both SXP and
>  JSON outputs of lx list -l
> > 
> > On Thu, 2013-06-20 at 13:00 +0100, Ian Murray wrote:
> >>  (Resent, as Yahoo seems to silently drop sentemail with the subject
> >>  starting with a square open bracket. Space inserted - apologies if
> >>  received more than once)
> > 
> > How very unhelpful of them! FWIW This seems to be the first one which
> > made it into the list archives as well as my INBOX.
> > 
> > I'm working through my post-vacation backlog this morning but I hope to
> > have a chance to look at this vs. 4.3-rc soon since I think it is a
> > worthwhile bugfix for 4.3. George, what does your release manager's hat
> > think?
> 
> There are white space issues with this patch on this thread as it is,
> so I re-issued it more recently directly from git, as is the preferred
> method I think.

It's certainly less error prone. Do you have the message-id handy so I
can find the right version?

> As was suggested by David Sutton, there are probably more issues with
> this script than has been covered so far, but this change makes
> suspension and restoration work for me, at least. He suggests there
> are problems with zombies, etc.

You mean the handling of zombies by this script, rather than it somehow
causing zombies?

Zombie domains are already themselves a bug in and of themselves so if
that can be reproduced we'd like to hear about it, as for the script's
handling of those zombies if/when they occur, I think it's probably
something to deal with in 4.4.

> >>  Modifications to xendomains so that it correctly identifies a new domain
> >>  entry when parsing the output of xl list -l. For both SXP and JSON
> >>  outputs, it was failing to spot a new domain entry and was saving the
> >>  second domain under a filename generated from the first domain's name.
> >> 
> >>  I have listed this as RFC because although it is a patch against 4.3RC5,
> >>  I have not had a chance to test against RC5, only 4.2.2. I won't get an
> >>  opportunity until the weekend, so I invite comment and anybody to give
> >>  it a test against RC5. Ian C has already commented elsewhere that the xl
> >>  list -l JSON output has been altered between 4.2.x and 4.3RC5, so this
> >>  might affect the indentation (the 4 spaces in the middle of the
> >>  LIST_GREP variable) - the trigger for new domain data is '    {' in 
> > JSON
> >>  version (in at least 4.2.2) and '(domain' in SXP version. Not 
> > tested
> >>  against xm.
> >> 
> >>  It seems there is a problem in 4.2.2's implementation of SXP output of
> >>  xl list -l in that all domain ID's are outputted as -1. Ian C suggested
> >>  applying a change that originally went into 4.3 to resolve this issue.
> >>  This seemed to do the trick (see thread [Xen-users] DomU
> >>  suspension/hibernation )
> > 
> > Would you be able to submit that backport as a patch against the 4.2
> > staging branch and CC myself and Ian Jackson
> > <ian.jackson@xxxxxxxxxxxxx> ?
> > 
> > This isn't a straight forward backport, since the majority of the commit
> > is not a suitable candidate, but if you reference in the commit message
> > the original commit id/subject and point out that only the one hunk is a
> > useful bug fix which is why it's been split out then I think it would be
> > fine to have in the next 4.2 release.
> 
> I'll give this a go, but it will be a learning experience. I don't
> recall seeing any backporting info in the patch submission notes but I
> will take another look.

Thanks. It's not that common to have to do things this way (mostly we
take the entire patch) so there isn't much in the way of docs. If you
just treat it for the most part like a regular submission and explain
what is going on in the commit message with references to the original
commit ID and title then you won't go far wrong.

>  Who signs a (partial) backport off? Can't be me, because I didn't
> write it. Or can it? or is it copied from the original submission?

I think it would be appropriate to retain the original signed-off-by(s)
and acks etc and append your own. Some people like to do:

  Commit message

  Signed-off-by: Original Author <original.author@xxxxxxxxxxx>
  Acked-by: 

  Backported to X.Y

  Signed-off-by: Back Porter <bporter@xxxxxxxxxxx>

Or something like that, which is fine IMHO. Or if your commit message
makes it clear enough what is going on then just tacking your S-o-b onto
the original blocks of S-o-b's would be fine.

Ian J, does that sound about right? The issue is that one hunk of
a73a7a0c647a "xl: Remove global domid and enable -Wshadow" is actually a
useful fix but the commit as a whole is large and unsuitable for
backporting IMHO.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel