Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Konrad Rzeszutek Wilk]

On 8/15/19 12:29 PM, Andrew Cooper wrote:

On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote:

Thanks Julien. I will do that next time (unless you guys want me to
re-send all this ;-)).

BTW, I also pushed my changes onto the xenbits server:
http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary
http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary

I hope that makes navigation and dealing with the swarm of patches a
bit easier.


Please (re)send two patch series, one for Xen and one for build tools.
Even for he subset you posted before, I can't figure out whether they're
ok to push straight away, or need more review.  This will be far easier
to do in one single go (per repo).


They look pretty good. Just need some extra test-cases.

And I will need to update the ts-livepatch test-case to take advantage 
of them.







___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Lars Kurth]

> On 15 Aug 2019, at 17:29, Andrew Cooper  wrote:
> 
> On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote:
>> Thanks Julien. I will do that next time (unless you guys want me to
>> re-send all this ;-)).
>> 
>> BTW, I also pushed my changes onto the xenbits server:
>> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary
>> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary
>> 
>> I hope that makes navigation and dealing with the swarm of patches a
>> bit easier.
> 
> Please (re)send two patch series, one for Xen and one for build tools. 
> Even for he subset you posted before, I can't figure out whether they're
> ok to push straight away, or need more review.  This will be far easier
> to do in one single go (per repo).
> 
> My workflow for series is something like this:
> 
> First, confirm your git settings (details as appropriate)
> 
> $ git config -l | grep sendemail
> sendemail.smtpserver= $SERVER
> sendemail.chainreplyto=false
> sendemail.to=Xen-devel 
> sendemail.from= $ME <$m...@example.com>
> 
> Second, render the patch series:
> 
> $ mkdir foo-v1
> $ cd foo-v1
> $ git format-patch master --cover-letter
> -cover-letter.patch
> 0001- 
> 
> 
> $ $EDITOR -cover-letter.patch
> 
> Fill in as appropriate.  Provide a brief overview, note the subject of
> companion series, etc.  I also include the union of all CC'd people in
> each patch just below the Subject: header which avoids having to
> manually specify them later.  Be aware that it is strict about RFCs, so
> has to be Cc: and not CC:
> 
> Third, double check everything:
> 
> $ git send-email --dry-run *.patch
> 
> Fourth, spam the list by dropping the --dry-run.
> 
> Fifth, sit back and watch the reviews come in[1].
> 
> ~Andrew

@Andrew: You just outlined what's in the wiki and what the add_maintainers tool 
does.

We should chat about the Cc: vs CC: 
* I may need to fix the tool as it uses CC: when used with some options

@Pawel: I submitted 
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01575.html 

https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01581.html 

which once applied ensures that the tools can be used on the live patch build 
tools

I also added 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Using_add_maintainers.pl_.28or_get_maintainer.pl.29_from_outside_of_xen.git
 


Lars

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Andrew Cooper]

On 15/08/2019 16:42, Wieczorkiewicz, Pawel wrote:
> Thanks Julien. I will do that next time (unless you guys want me to
> re-send all this ;-)).
>
> BTW, I also pushed my changes onto the xenbits server:
> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary
> http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary
>
> I hope that makes navigation and dealing with the swarm of patches a
> bit easier.

Please (re)send two patch series, one for Xen and one for build tools. 
Even for he subset you posted before, I can't figure out whether they're
ok to push straight away, or need more review.  This will be far easier
to do in one single go (per repo).

My workflow for series is something like this:

First, confirm your git settings (details as appropriate)

$ git config -l | grep sendemail
sendemail.smtpserver= $SERVER
sendemail.chainreplyto=false
sendemail.to=Xen-devel 
sendemail.from= $ME <$m...@example.com>

Second, render the patch series:

$ mkdir foo-v1
$ cd foo-v1
$ git format-patch master --cover-letter
-cover-letter.patch
0001- 


$ $EDITOR -cover-letter.patch

Fill in as appropriate.  Provide a brief overview, note the subject of
companion series, etc.  I also include the union of all CC'd people in
each patch just below the Subject: header which avoids having to
manually specify them later.  Be aware that it is strict about RFCs, so
has to be Cc: and not CC:

Third, double check everything:

$ git send-email --dry-run *.patch

Fourth, spam the list by dropping the --dry-run.

Fifth, sit back and watch the reviews come in[1].

~Andrew

[1] Who am I kidding? This is invariably "pick up one of the other
urgent tasks that you put to one side a little while ago..."  ;)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[George Dunlap]

On 8/15/19 5:00 PM, Julien Grall wrote:
> Hi George,
> 
> On 15/08/2019 16:48, George Dunlap wrote:
>> On 8/15/19 4:36 PM, Julien Grall wrote:
>>> Hi George,
>>>
>>> On 15/08/2019 16:32, George Dunlap wrote:
 On 8/15/19 4:29 PM, Julien Grall wrote:
>
>
> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:
>> Hi Lars, Julien,
>
> Hi,
>
>> Thanks for the pointers, I will read them up and follow the
>> recommendations with my future contributions.
>> Sorry for the mess…
>>
>> But, let me ask first before reading the wikis, how do you prefer
>> submitting series that contain patches belonging to 2 distinct repos
>> (e.g. xen and livepatch-build-tools)?
>
> I can see two ways:
>
>     1) One series per project and mention in the cover letter that
> modifications are required in another project (with link/title).
>     2) Combine all the patches in one series and tag them differently.
> I.e
> [XEN] [LIVEPATCH].
>
> 1) is preferable if you have a lot of patches in each repo. 2) can be
> handy if you have only a couple of patches for one repo.

 1 is also easier for automated tools (like patchew) to deal with.
>>>
>>> Out of interest, in general developer will tend to cross-post those
>>> patches. So in what way this would make it easier?
>>
>> If you have two separate series, then patchew will be able to handle one
>> and not handle the other.  If they're mixed in a single series, patchew
>> won't be able to handle it at all.  At the moment patchew doesn't do
>> anything but give you a nice mbox / git branch to pull; but eventually
>> the idea is that it will do some level of testing and give feedback
>> (patch does/n't apply, patch does/n't build, patch does/n't pass smoke
>> tests / ).
> 
> Oh, so patchew will try to apply the series. If it does not fully apply,
> then it means the series does not target Xen, right?

Either that, or the series needs to be rebased.  I rather doubt the
patchew authors have spent a lot of time trying to distinguish the two. :-)

> I haven't used much patchew so far, but it looks like I should give a
> try when committing/reviewing series :).

Yes, I've found it quite useful.  It automatically adds acks and r-b's
as they're given, and also adds the message id into the commit message,
which could be useful.

One warning: Don't use patchew's branch if you think you might commit a
series, because the "committer" is always listed as patchew, rather than
yourself.  You can see a couple of places in recent history where I've
done this, not realizing; but I think it's something we want to avoid.
Use the mbox to apply the series instead.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Lars Kurth]

> On 15 Aug 2019, at 16:58, Julien Grall  wrote:
> 
> Hi Lars,
> 
> On 15/08/2019 16:46, Lars Kurth wrote:
>>> On 15 Aug 2019, at 16:33, Lars Kurth >> > wrote:
>>> 
>>> 
>>> 
 On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel >>> > wrote:
 
 Hi Lars, Julien,
 
 Thanks for the pointers, I will read them up and follow the 
 recommendations with my future contributions.
 Sorry for the mess…
>>> 
>>> It's not really a mess: it must have been quite a pain to put the mails 
>>> together manually
>>> And it would become more painful for a second revision
>>> I have been through this myself
>>> 
 But, let me ask first before reading the wikis, how do you prefer 
 submitting series that contain patches belonging to 2 distinct repos (e.g. 
 xen and livepatch-build-tools)?
>>> 
>>> That's a good question and a very rare use-case. We split them, as all the 
>>> tools such as git format-patch only work on one repo
>>> Applying patches also only works on a per repo basis
>>> 
>>> So, I would send two series. But mention the relationship in the cover 
>>> letter (and/or patch if it is a single one)
>>> 
>>> The tools in the docs currently may not work on livepatch-build-tools.git
>>> * First: there is no MAINTAINERS file in livepatch-build-tools.git, which 
>>> really should be added
>>> * Second: using xen.git:/scripts/add_maintainers.pl may not work when 
>>> called from within livepatch-build-tools.git
>>> 
>>> I am going to play with this and update the docs and if needed the tools 
>>> accordingly
>>> You may have to improvise in the meantime:
>>> * Step 1 & 3 will work: Step 2, option 1 will probably not (which means 
>>> until I have done this, you may have to follow option 2 and make sure that 
>>> the right people are CC'ed)
>> I can confirm that Step 2 does not work without some tools changes to 
>> scripts/add_maintainers.pl when called from within a non-xen.git repo
>> And
>> git send-email --to xen-devel@lists.xenproject.org 
>>  
>> --cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1
>> errors with
>> ../xen.git/scripts/get_maintainer.pl: The current directory does not appear 
>> to be a Xen source tree.
>> I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the 
>> actual Xen tree
> 
> get_maintainer.pl relies on the current working directory to be the top of 
> tree.
> 
> At the moment, it checks various file are present (see top_of_tree) but I 
> think it should be feasible to just relax it to just MAINTAINERS.
> 
> The risk is a user may end up to call the wrong MAINTAINERS file if it messes 
> up the current working directory (i.e calling for Xen patches from 
> livepatch-tools). Not sure if this is a real concern though...
> 
> Note that Linux has a similar check to ensure the user is on the right 
> directory (i.e

I know, that's where we inherited that from. I suppose the issue is that the 
MAINTAINERS file format may be different in another tree and thus the tool may 
fall over.

In any case: I have a patch which prints out a warning rather than abort

I will send once I made corresponding change to get_maintainers.pl, which seems 
to have call locations to add_maintainers.pl hardcoded in it

Lars
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Julien Grall]

Hi George,

On 15/08/2019 16:48, George Dunlap wrote:

On 8/15/19 4:36 PM, Julien Grall wrote:

Hi George,

On 15/08/2019 16:32, George Dunlap wrote:

On 8/15/19 4:29 PM, Julien Grall wrote:



On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:

Hi Lars, Julien,


Hi,


Thanks for the pointers, I will read them up and follow the
recommendations with my future contributions.
Sorry for the mess…

But, let me ask first before reading the wikis, how do you prefer
submitting series that contain patches belonging to 2 distinct repos
(e.g. xen and livepatch-build-tools)?


I can see two ways:

    1) One series per project and mention in the cover letter that
modifications are required in another project (with link/title).
    2) Combine all the patches in one series and tag them differently.
I.e
[XEN] [LIVEPATCH].

1) is preferable if you have a lot of patches in each repo. 2) can be
handy if you have only a couple of patches for one repo.


1 is also easier for automated tools (like patchew) to deal with.


Out of interest, in general developer will tend to cross-post those
patches. So in what way this would make it easier?


If you have two separate series, then patchew will be able to handle one
and not handle the other.  If they're mixed in a single series, patchew
won't be able to handle it at all.  At the moment patchew doesn't do
anything but give you a nice mbox / git branch to pull; but eventually
the idea is that it will do some level of testing and give feedback
(patch does/n't apply, patch does/n't build, patch does/n't pass smoke
tests / ).


Oh, so patchew will try to apply the series. If it does not fully apply, then it 
means the series does not target Xen, right?


I haven't used much patchew so far, but it looks like I should give a try when 
committing/reviewing series :).


Thank you for the explanation!

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Julien Grall]

Hi Lars,

On 15/08/2019 16:46, Lars Kurth wrote:



On 15 Aug 2019, at 16:33, Lars Kurth > wrote:




On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel > wrote:


Hi Lars, Julien,

Thanks for the pointers, I will read them up and follow the recommendations 
with my future contributions.

Sorry for the mess…


It's not really a mess: it must have been quite a pain to put the mails 
together manually

And it would become more painful for a second revision
I have been through this myself

But, let me ask first before reading the wikis, how do you prefer submitting 
series that contain patches belonging to 2 distinct repos (e.g. xen and 
livepatch-build-tools)?


That's a good question and a very rare use-case. We split them, as all the 
tools such as git format-patch only work on one repo

Applying patches also only works on a per repo basis

So, I would send two series. But mention the relationship in the cover letter 
(and/or patch if it is a single one)


The tools in the docs currently may not work on livepatch-build-tools.git
* First: there is no MAINTAINERS file in livepatch-build-tools.git, which 
really should be added
* Second: using xen.git:/scripts/add_maintainers.pl may not work when called 
from within livepatch-build-tools.git


I am going to play with this and update the docs and if needed the tools 
accordingly

You may have to improvise in the meantime:
* Step 1 & 3 will work: Step 2, option 1 will probably not (which means until 
I have done this, you may have to follow option 2 and make sure that the right 
people are CC'ed)


I can confirm that Step 2 does not work without some tools changes to 
scripts/add_maintainers.pl when called from within a non-xen.git repo


And

git send-email --to xen-devel@lists.xenproject.org 
 
--cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1


errors with

../xen.git/scripts/get_maintainer.pl: The current directory does not appear to 
be a Xen source tree.


I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the 
actual Xen tree


get_maintainer.pl relies on the current working directory to be the top of tree.

At the moment, it checks various file are present (see top_of_tree) but I think 
it should be feasible to just relax it to just MAINTAINERS.


The risk is a user may end up to call the wrong MAINTAINERS file if it messes up 
the current working directory (i.e calling for Xen patches from 
livepatch-tools). Not sure if this is a real concern though...


Note that Linux has a similar check to ensure the user is on the right directory 
(i.e


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[George Dunlap]

On 8/15/19 4:36 PM, Julien Grall wrote:
> Hi George,
> 
> On 15/08/2019 16:32, George Dunlap wrote:
>> On 8/15/19 4:29 PM, Julien Grall wrote:
>>>
>>>
>>> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:
 Hi Lars, Julien,
>>>
>>> Hi,
>>>
 Thanks for the pointers, I will read them up and follow the
 recommendations with my future contributions.
 Sorry for the mess…

 But, let me ask first before reading the wikis, how do you prefer
 submitting series that contain patches belonging to 2 distinct repos
 (e.g. xen and livepatch-build-tools)?
>>>
>>> I can see two ways:
>>>
>>>    1) One series per project and mention in the cover letter that
>>> modifications are required in another project (with link/title).
>>>    2) Combine all the patches in one series and tag them differently.
>>> I.e
>>> [XEN] [LIVEPATCH].
>>>
>>> 1) is preferable if you have a lot of patches in each repo. 2) can be
>>> handy if you have only a couple of patches for one repo.
>>
>> 1 is also easier for automated tools (like patchew) to deal with.
> 
> Out of interest, in general developer will tend to cross-post those
> patches. So in what way this would make it easier?

If you have two separate series, then patchew will be able to handle one
and not handle the other.  If they're mixed in a single series, patchew
won't be able to handle it at all.  At the moment patchew doesn't do
anything but give you a nice mbox / git branch to pull; but eventually
the idea is that it will do some level of testing and give feedback
(patch does/n't apply, patch does/n't build, patch does/n't pass smoke
tests / ).

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Lars Kurth]

> On 15 Aug 2019, at 16:33, Lars Kurth  wrote:
> 
> 
> 
>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel > > wrote:
>> 
>> Hi Lars, Julien,
>> 
>> Thanks for the pointers, I will read them up and follow the recommendations 
>> with my future contributions.
>> Sorry for the mess…
> 
> It's not really a mess: it must have been quite a pain to put the mails 
> together manually
> And it would become more painful for a second revision
> I have been through this myself
> 
>> But, let me ask first before reading the wikis, how do you prefer submitting 
>> series that contain patches belonging to 2 distinct repos (e.g. xen and 
>> livepatch-build-tools)?
> 
> That's a good question and a very rare use-case. We split them, as all the 
> tools such as git format-patch only work on one repo
> Applying patches also only works on a per repo basis
> 
> So, I would send two series. But mention the relationship in the cover letter 
> (and/or patch if it is a single one)
> 
> The tools in the docs currently may not work on livepatch-build-tools.git
> * First: there is no MAINTAINERS file in livepatch-build-tools.git, which 
> really should be added
> * Second: using xen.git:/scripts/add_maintainers.pl may not work when called 
> from within livepatch-build-tools.git
> 
> I am going to play with this and update the docs and if needed the tools 
> accordingly
> You may have to improvise in the meantime:
> * Step 1 & 3 will work: Step 2, option 1 will probably not (which means until 
> I have done this, you may have to follow option 2 and make sure that the 
> right people are CC'ed)

I can confirm that Step 2 does not work without some tools changes to 
scripts/add_maintainers.pl when called from within a non-xen.git repo

And 

git send-email --to xen-devel@lists.xenproject.org 
--cc-cmd="../xen.git/scripts/get_maintainer.pl" --dry-run -1

errors with 

../xen.git/scripts/get_maintainer.pl: The current directory does not appear to 
be a Xen source tree.

I need to fix this. Hopefully get_maintainer.pl isn't too dependant on the 
actual Xen tree

Lars


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Wieczorkiewicz, Pawel]

Thanks Julien. I will do that next time (unless you guys want me to re-send all 
this ;-)).

BTW, I also pushed my changes onto the xenbits server:
http://xenbits.xenproject.org/gitweb/?p=people/wipawel/livepatch-build-tools;a=summary
http://xenbits.xenproject.org/gitweb/?p=people/wipawel/xen;a=summary

I hope that makes navigation and dealing with the swarm of patches a bit easier.

Best Regards,
Pawel Wieczorkiewicz



On 15. Aug 2019, at 17:29, Julien Grall 
mailto:julien.gr...@arm.com>> wrote:



On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:
Hi Lars, Julien,

Hi,

Thanks for the pointers, I will read them up and follow the recommendations 
with my future contributions.
Sorry for the mess…
But, let me ask first before reading the wikis, how do you prefer submitting 
series that contain patches belonging to 2 distinct repos (e.g. xen and 
livepatch-build-tools)?

I can see two ways:

 1) One series per project and mention in the cover letter that modifications 
are required in another project (with link/title).
 2) Combine all the patches in one series and tag them differently. I.e [XEN] 
[LIVEPATCH].

1) is preferable if you have a lot of patches in each repo. 2) can be handy if 
you have only a couple of patches for one repo.

Cheers,

Best Regards,
Pawel Wieczorkiewicz
On 15. Aug 2019, at 16:58, Lars Kurth 
mailto:lars.kurth@gmail.com> 
> wrote:



On 15 Aug 2019, at 12:38, Julien Grall 
mailto:julien.gr...@arm.com> 
> wrote:

Hi,

I am not going to answer on the patch itself but the process.

Any series (i.e more than one patch) should contain a cover letter with a rough 
summary of the goal of the series.

Furthermore, this 3 patches series has been received as 3 separate threads (i.e 
in-reply-to is missing). This is making difficult to know that all the patches 
belongs to the same series. In general, all patches are send as in-reply-to the 
cover letter. So all the patches sticks together in one thread.

The cover letter can be generated via git format-patch --cover-letter. 
Threading is done automatically with git-send-email when all the patches as 
passed in arguments.

For more details how to do it, you can read:

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series

Cheers,

Hi Pawel,

thank you for submitting the patch series.

We had a couple of new starters recently who followed a similar pattern to you. 
As a result of this, I recently updated the following docs

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - Definitions 
and general workflow
The bit which saves the most work is 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
As for Julien's comment on the threading: see the --thread and --cover-letter 
option as described in the Sending a Patch Series

https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git - Basic Git 
commands fitting into the workflow, including how to deal with reviews
https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit - Basic StGit 
commands fitting into the workflow, including how to deal with reviews
I have not had time to play with git series yet. If anyone in your team uses it 
let me know

In any case: if you follow the instructions the entire submission process and 
dealing with review comments becomes much easier.

As a newcomer, to contributing to Xen, I would greatly appreciate if you could 
let me know of any issues with the docs, such that we can fix them

Regards
Lars



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

--
Julien Grall




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Julien Grall]

Hi George,

On 15/08/2019 16:32, George Dunlap wrote:

On 8/15/19 4:29 PM, Julien Grall wrote:



On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:

Hi Lars, Julien,


Hi,


Thanks for the pointers, I will read them up and follow the
recommendations with my future contributions.
Sorry for the mess…

But, let me ask first before reading the wikis, how do you prefer
submitting series that contain patches belonging to 2 distinct repos
(e.g. xen and livepatch-build-tools)?


I can see two ways:

   1) One series per project and mention in the cover letter that
modifications are required in another project (with link/title).
   2) Combine all the patches in one series and tag them differently. I.e
[XEN] [LIVEPATCH].

1) is preferable if you have a lot of patches in each repo. 2) can be
handy if you have only a couple of patches for one repo.


1 is also easier for automated tools (like patchew) to deal with.


Out of interest, in general developer will tend to cross-post those patches. So 
in what way this would make it easier?


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Lars Kurth]

> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel  wrote:
> 
> Hi Lars, Julien,
> 
> Thanks for the pointers, I will read them up and follow the recommendations 
> with my future contributions.
> Sorry for the mess…

It's not really a mess: it must have been quite a pain to put the mails 
together manually
And it would become more painful for a second revision
I have been through this myself

> But, let me ask first before reading the wikis, how do you prefer submitting 
> series that contain patches belonging to 2 distinct repos (e.g. xen and 
> livepatch-build-tools)?

That's a good question and a very rare use-case. We split them, as all the 
tools such as git format-patch only work on one repo
Applying patches also only works on a per repo basis

So, I would send two series. But mention the relationship in the cover letter 
(and/or patch if it is a single one)

The tools in the docs currently may not work on livepatch-build-tools.git
* First: there is no MAINTAINERS file in livepatch-build-tools.git, which 
really should be added
* Second: using xen.git:/scripts/add_maintainers.pl may not work when called 
from within livepatch-build-tools.git

I am going to play with this and update the docs and if needed the tools 
accordingly
You may have to improvise in the meantime:
* Step 1 & 3 will work: Step 2, option 1 will probably not (which means until I 
have done this, you may have to follow option 2 and make sure that the right 
people are CC'ed)

You can also use: https://patchew.org/Xen/ , 
https://patchwork.kernel.org/project/xen-devel/list/ 
 or 
https://lore.kernel.org/xen-devel/  to 
track some of the changes. I have not had time to add this to the docs yet

Lars

> 
> Best Regards,
> Pawel Wieczorkiewicz
> 
> 
> 
>> On 15. Aug 2019, at 16:58, Lars Kurth > > wrote:
>> 
>> 
>> 
>>> On 15 Aug 2019, at 12:38, Julien Grall >> > wrote:
>>> 
>>> Hi,
>>> 
>>> I am not going to answer on the patch itself but the process.
>>> 
>>> Any series (i.e more than one patch) should contain a cover letter with a 
>>> rough summary of the goal of the series.
>>> 
>>> Furthermore, this 3 patches series has been received as 3 separate threads 
>>> (i.e in-reply-to is missing). This is making difficult to know that all the 
>>> patches belongs to the same series. In general, all patches are send as 
>>> in-reply-to the cover letter. So all the patches sticks together in one 
>>> thread.
>>> 
>>> The cover letter can be generated via git format-patch --cover-letter. 
>>> Threading is done automatically with git-send-email when all the patches as 
>>> passed in arguments.
>>> 
>>> For more details how to do it, you can read:
>>> 
>>> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
>>>  
>>> 
>>> 
>>> Cheers,
>> 
>> Hi Pawel, 
>> 
>> thank you for submitting the patch series. 
>> 
>> We had a couple of new starters recently who followed a similar pattern to 
>> you. As a result of this, I recently updated the following docs
>> 
>> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches 
>>  - 
>> Definitions and general workflow
>> The bit which saves the most work is 
>> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
>>  
>> 
>> As for Julien's comment on the threading: see the --thread and 
>> --cover-letter option as described in the Sending a Patch Series
>> 
>> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git 
>>  - Basic Git 
>> commands fitting into the workflow, including how to deal with reviews
>> https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit 
>>  - Basic 
>> StGit commands fitting into the workflow, including how to deal with reviews
>> I have not had time to play with git series yet. If anyone in your team uses 
>> it let me know
>> 
>> In any case: if you follow the instructions the entire submission process 
>> and dealing with review comments becomes much easier. 
>> 
>> As a newcomer, to contributing to Xen, I would greatly appreciate if you 
>> could let me know of any issues with the docs, such that we can fix them
>> 
>> Regards
>> Lars
>> 
>> 
>> 
> 
> 
> 
> 
> Amazon Development Center Germany GmbH 
> Krausenstr. 38 
> 10117 Berlin 
> Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich 
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B 
> Sitz: Berlin 
> Ust-ID: DE 289 237 879 
> 
> 

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[George Dunlap]

On 8/15/19 4:29 PM, Julien Grall wrote:
> 
> 
> On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:
>> Hi Lars, Julien,
> 
> Hi,
> 
>> Thanks for the pointers, I will read them up and follow the
>> recommendations with my future contributions.
>> Sorry for the mess…
>>
>> But, let me ask first before reading the wikis, how do you prefer
>> submitting series that contain patches belonging to 2 distinct repos
>> (e.g. xen and livepatch-build-tools)?
> 
> I can see two ways:
> 
>   1) One series per project and mention in the cover letter that
> modifications are required in another project (with link/title).
>   2) Combine all the patches in one series and tag them differently. I.e
> [XEN] [LIVEPATCH].
> 
> 1) is preferable if you have a lot of patches in each repo. 2) can be
> handy if you have only a couple of patches for one repo.

1 is also easier for automated tools (like patchew) to deal with.

 -George

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Julien Grall]

On 15/08/2019 16:19, Wieczorkiewicz, Pawel wrote:

Hi Lars, Julien,


Hi,

Thanks for the pointers, I will read them up and follow the recommendations with 
my future contributions.

Sorry for the mess…

But, let me ask first before reading the wikis, how do you prefer submitting 
series that contain patches belonging to 2 distinct repos (e.g. xen and 
livepatch-build-tools)?


I can see two ways:

  1) One series per project and mention in the cover letter that modifications 
are required in another project (with link/title).
  2) Combine all the patches in one series and tag them differently. I.e [XEN] 
[LIVEPATCH].


1) is preferable if you have a lot of patches in each repo. 2) can be handy if 
you have only a couple of patches for one repo.


Cheers,



Best Regards,
Pawel Wieczorkiewicz



On 15. Aug 2019, at 16:58, Lars Kurth > wrote:




On 15 Aug 2019, at 12:38, Julien Grall > wrote:


Hi,

I am not going to answer on the patch itself but the process.

Any series (i.e more than one patch) should contain a cover letter with a 
rough summary of the goal of the series.


Furthermore, this 3 patches series has been received as 3 separate threads 
(i.e in-reply-to is missing). This is making difficult to know that all the 
patches belongs to the same series. In general, all patches are send as 
in-reply-to the cover letter. So all the patches sticks together in one thread.


The cover letter can be generated via git format-patch --cover-letter. 
Threading is done automatically with git-send-email when all the patches as 
passed in arguments.


For more details how to do it, you can read:

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series

Cheers,


Hi Pawel,

thank you for submitting the patch series.

We had a couple of new starters recently who followed a similar pattern to 
you. As a result of this, I recently updated the following docs


https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - Definitions 
and general workflow
The bit which saves the most work is 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
As for Julien's comment on the threading: see the --thread and --cover-letter 
option as described in the Sending a Patch Series


https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git - Basic Git 
commands fitting into the workflow, including how to deal with reviews
https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit - Basic StGit 
commands fitting into the workflow, including how to deal with reviews
I have not had time to play with git series yet. If anyone in your team uses 
it let me know


In any case: if you follow the instructions the entire submission process and 
dealing with review comments becomes much easier.


As a newcomer, to contributing to Xen, I would greatly appreciate if you could 
let me know of any issues with the docs, such that we can fix them


Regards
Lars








Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879




--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Wieczorkiewicz, Pawel]

Hi Lars, Julien,

Thanks for the pointers, I will read them up and follow the recommendations 
with my future contributions.
Sorry for the mess…

But, let me ask first before reading the wikis, how do you prefer submitting 
series that contain patches belonging to 2 distinct repos (e.g. xen and 
livepatch-build-tools)?

Best Regards,
Pawel Wieczorkiewicz



On 15. Aug 2019, at 16:58, Lars Kurth 
mailto:lars.kurth@gmail.com>> wrote:



On 15 Aug 2019, at 12:38, Julien Grall 
mailto:julien.gr...@arm.com>> wrote:

Hi,

I am not going to answer on the patch itself but the process.

Any series (i.e more than one patch) should contain a cover letter with a rough 
summary of the goal of the series.

Furthermore, this 3 patches series has been received as 3 separate threads (i.e 
in-reply-to is missing). This is making difficult to know that all the patches 
belongs to the same series. In general, all patches are send as in-reply-to the 
cover letter. So all the patches sticks together in one thread.

The cover letter can be generated via git format-patch --cover-letter. 
Threading is done automatically with git-send-email when all the patches as 
passed in arguments.

For more details how to do it, you can read:

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series

Cheers,

Hi Pawel,

thank you for submitting the patch series.

We had a couple of new starters recently who followed a similar pattern to you. 
As a result of this, I recently updated the following docs

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches - Definitions 
and general workflow
The bit which saves the most work is 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
As for Julien's comment on the threading: see the --thread and --cover-letter 
option as described in the Sending a Patch Series

https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git - Basic Git 
commands fitting into the workflow, including how to deal with reviews
https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit - Basic StGit 
commands fitting into the workflow, including how to deal with reviews
I have not had time to play with git series yet. If anyone in your team uses it 
let me know

In any case: if you follow the instructions the entire submission process and 
dealing with review comments becomes much easier.

As a newcomer, to contributing to Xen, I would greatly appreciate if you could 
let me know of any issues with the docs, such that we can fix them

Regards
Lars







Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Lars Kurth]

> On 15 Aug 2019, at 12:38, Julien Grall  wrote:
> 
> Hi,
> 
> I am not going to answer on the patch itself but the process.
> 
> Any series (i.e more than one patch) should contain a cover letter with a 
> rough summary of the goal of the series.
> 
> Furthermore, this 3 patches series has been received as 3 separate threads 
> (i.e in-reply-to is missing). This is making difficult to know that all the 
> patches belongs to the same series. In general, all patches are send as 
> in-reply-to the cover letter. So all the patches sticks together in one 
> thread.
> 
> The cover letter can be generated via git format-patch --cover-letter. 
> Threading is done automatically with git-send-email when all the patches as 
> passed in arguments.
> 
> For more details how to do it, you can read:
> 
> https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
>  
> 
> 
> Cheers,

Hi Pawel, 

thank you for submitting the patch series. 

We had a couple of new starters recently who followed a similar pattern to you. 
As a result of this, I recently updated the following docs

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches 
 - Definitions 
and general workflow
The bit which saves the most work is 
https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series
 

As for Julien's comment on the threading: see the --thread and --cover-letter 
option as described in the Sending a Patch Series

https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_Git 
 - Basic Git 
commands fitting into the workflow, including how to deal with reviews
https://wiki.xenproject.org/wiki/Managing_Xen_Patches_with_StGit 
 - Basic 
StGit commands fitting into the workflow, including how to deal with reviews
I have not had time to play with git series yet. If anyone in your team uses it 
let me know

In any case: if you follow the instructions the entire submission process and 
dealing with review comments becomes much easier. 

As a newcomer, to contributing to Xen, I would greatly appreciate if you could 
let me know of any issues with the docs, such that we can fix them

Regards
Lars



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation

[Julien Grall]

Hi,

I am not going to answer on the patch itself but the process.

Any series (i.e more than one patch) should contain a cover letter with a rough 
summary of the goal of the series.


Furthermore, this 3 patches series has been received as 3 separate threads (i.e 
in-reply-to is missing). This is making difficult to know that all the patches 
belongs to the same series. In general, all patches are send as in-reply-to the 
cover letter. So all the patches sticks together in one thread.


The cover letter can be generated via git format-patch --cover-letter. Threading 
is done automatically with git-send-email when all the patches as passed in 
arguments.


For more details how to do it, you can read:

https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Sending_a_Patch_Series

Cheers,

On 15/08/2019 12:27, Pawel Wieczorkiewicz wrote:

The payloads' name strings can be of arbitrary size (typically small
with an upper bound of XEN_LIVEPATCH_NAME_SIZE).
Current implementation of the list operation interface allows to copy
names in the XEN_LIVEPATCH_NAME_SIZE chunks regardless of its actual
size and enforces space allocation requirements on userland tools.

To unify and simplify the interface, handle the name strings of
arbitrary size by copying them in adhering chunks to the userland.
In order to let the userland allocate enough space for the incoming
data add an auxiliary interface xc_livepatch_list_get_sizes() that
provides the current number of payload entries and the total size of
all name strings. This is achieved by extending the sysctl list
interface with an extra fields: name_total_size.

The xc_livepatch_list_get_sizes() issues the livepatch sysctl list
operation with the nr field set to 0. In this mode the operation
returns the number of payload entries and calculates the total sizes
for all payloads' names.
When the sysctl operation is issued with a non-zero nr field (for
instance with a value obtained earlier with the prior call to the
xc_livepatch_list_get_sizes()) the new field name_total_size provides
the total size of actually copied data.

Extend the libxc to handle the name back-to-back data transfers.

The xen-livepatch tool is modified to start the list operation with a
call to the xc_livepatch_list_get_sizes() to obtain the actual number
of payloads as well as the necessary space for names.
The tool now always requests the actual number of entries and leaves
the preemption handling to the libxc routine. The libxc still returns
'done' and 'left' parameters with the same semantic allowing the tool
to detect anomalies and react to them. At the moment it is expected
that the tool receives the exact number of entires as requested.
The xen-livepatch tool has been also modified to handle the name
back-to-back transfers correctly.

Signed-off-by: Pawel Wieczorkiewicz 
Reviewed-by: Andra-Irina Paraschiv 
Reviewed-by: Bjoern Doebel 
Reviewed-by: Martin Pohlack 
---
  tools/libxc/include/xenctrl.h |  49 --
  tools/libxc/xc_misc.c | 100 -
  tools/misc/xen-livepatch.c| 112 ++
  xen/common/livepatch.c|  31 +---
  xen/include/public/sysctl.h   |  15 +++---
  5 files changed, 204 insertions(+), 103 deletions(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 725697c132..e0ebb586b6 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2560,7 +2560,25 @@ int xc_livepatch_get(xc_interface *xch,
   xen_livepatch_status_t *status);
  
  /*

- * The heart of this function is to get an array of xen_livepatch_status_t.
+ * Get a number of available payloads and get actual total size of
+ * the payloads' name array.
+ *
+ * This functions is typically executed first before the xc_livepatch_list()
+ * to obtain the sizes and correctly allocate all necessary data resources.
+ *
+ * The return value is zero if the hypercall completed successfully.
+ *
+ * If there was an error performing the sysctl operation, the return value
+ * will contain the hypercall error code value.
+ */
+int xc_livepatch_list_get_sizes(xc_interface *xch, unsigned int *nr,
+uint64_t *name_total_size);
+
+/*


git-send-email can do that for you.


1) Any series (i.e more than one patch) should contain a cover letter
2)


+ * The heart of this function is to get an array of the following objects:
+ *   - xen_livepatch_status_t: states and return codes of payloads
+ *   - name: names of payloads
+ *   - len: lengths of corresponding payloads' names
   *
   * However it is complex because it has to deal with the hypervisor
   * returning some of the requested data or data being stale
@@ -2571,21 +2589,20 @@ int xc_livepatch_get(xc_interface *xch,
   * 'left' are also updated with the number of entries filled out
   * and respectively the number of entries left to get from hypervisor.
   *
- *