xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
* [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
@ 2019-08-15 11:27 Pawel Wieczorkiewicz
  2019-08-15 11:38 ` Julien Grall
  0 siblings, 1 reply; 18+ messages in thread
From: Pawel Wieczorkiewicz @ 2019-08-15 11:27 UTC (permalink / raw)
  To: xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ross Lagerwall, Ian Jackson,
	Tim Deegan, mpohlack, wipawel, Julien Grall, Jan Beulich,
	xen-devel

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 <wipawel@amazon.de>
Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
Reviewed-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
---
 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);
+
+/*
+ * 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.
  *
- * It is expected that the caller of this function will take the
- * 'left' and use the value for 'start'. This way we have an
- * cursor in the array. Note that the 'info','name', and 'len' will
- * be updated at the subsequent calls.
+ * It is expected that the caller of this function will first issue the
+ * xc_livepatch_list_get_sizes() in order to obtain total sizes of names
+ * as well as the current number of payload entries.
+ * The total sizes are required and supplied via the 'name_total_size'
+ * parameter.
  *
- * The 'max' is to be provided by the caller with the maximum
- * number of entries that 'info', 'name', and 'len' arrays can
- * be filled up with.
- *
- * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE
- * length.
+ * The 'max' is to be provided by the caller with the maximum number of
+ * entries that 'info', 'name', 'len' arrays can be filled up with.
  *
  * Each entry in the 'info' array is expected to be of xen_livepatch_status_t
  * structure size.
  *
+ * Each entry in the 'name' array may have an arbitrary size.
+ *
  * Each entry in the 'len' array is expected to be of uint32_t size.
  *
  * The return value is zero if the hypercall completed successfully.
@@ -2597,10 +2614,12 @@ int xc_livepatch_get(xc_interface *xch,
  * will contain the number of entries that had been succesfully
  * retrieved (if any).
  */
-int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
-                      xen_livepatch_status_t *info, char *name,
-                      uint32_t *len, unsigned int *done,
-                      unsigned int *left);
+int xc_livepatch_list(xc_interface *xch, const unsigned int max,
+                      const unsigned int start,
+                      struct xen_livepatch_status *info,
+                      char *name, uint32_t *len,
+                      const uint64_t name_total_size,
+                      unsigned int *done, unsigned int *left);
 
 /*
  * The operations are asynchronous and the hypervisor may take a while
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index a8e9e7d1e2..d787f3f29f 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -662,7 +662,48 @@ int xc_livepatch_get(xc_interface *xch,
 }
 
 /*
- * 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)
+{
+    DECLARE_SYSCTL;
+    int rc;
+
+    if ( !nr || !name_total_size )
+    {
+        errno = EINVAL;
+        return -1;
+    }
+
+    memset(&sysctl, 0, sizeof(sysctl));
+    sysctl.cmd = XEN_SYSCTL_livepatch_op;
+    sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST;
+
+    rc = do_sysctl(xch, &sysctl);
+    if ( rc )
+        return rc;
+
+    *nr = sysctl.u.livepatch.u.list.nr;
+    *name_total_size = sysctl.u.livepatch.u.list.name_total_size;
+
+    return 0;
+}
+
+/*
+ * 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
@@ -673,21 +714,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.
  *
- * It is expected that the caller of this function will take the
- * 'left' and use the value for 'start'. This way we have an
- * cursor in the array. Note that the 'info','name', and 'len' will
- * be updated at the subsequent calls.
+ * It is expected that the caller of this function will first issue the
+ * xc_livepatch_list_get_sizes() in order to obtain total sizes of names
+ * as well as the current number of payload entries.
+ * The total sizes are required and supplied via the 'name_total_size'
+ * parameter.
  *
- * The 'max' is to be provided by the caller with the maximum
- * number of entries that 'info', 'name', and 'len' arrays can
- * be filled up with.
- *
- * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE
- * length.
+ * The 'max' is to be provided by the caller with the maximum number of
+ * entries that 'info', 'name', 'len' arrays can be filled up with.
  *
  * Each entry in the 'info' array is expected to be of xen_livepatch_status_t
  * structure size.
  *
+ * Each entry in the 'name' array may have an arbitrary size.
+ *
  * Each entry in the 'len' array is expected to be of uint32_t size.
  *
  * The return value is zero if the hypercall completed successfully.
@@ -699,11 +739,12 @@ int xc_livepatch_get(xc_interface *xch,
  * will contain the number of entries that had been succesfully
  * retrieved (if any).
  */
-int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
+int xc_livepatch_list(xc_interface *xch, const unsigned int max,
+                      const unsigned int start,
                       struct xen_livepatch_status *info,
                       char *name, uint32_t *len,
-                      unsigned int *done,
-                      unsigned int *left)
+                      const uint64_t name_total_size,
+                      unsigned int *done, unsigned int *left)
 {
     int rc;
     DECLARE_SYSCTL;
@@ -714,27 +755,33 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
     uint32_t max_batch_sz, nr;
     uint32_t version = 0, retries = 0;
     uint32_t adjust = 0;
-    ssize_t sz;
+    off_t name_off = 0;
+    uint64_t name_sz;
 
-    if ( !max || !info || !name || !len )
+    if ( !max || !info || !name || !len || !done || !left )
     {
         errno = EINVAL;
         return -1;
     }
 
+    if ( name_total_size == 0 )
+    {
+        errno = ENOENT;
+        return -1;
+    }
+
+    memset(&sysctl, 0, sizeof(sysctl));
     sysctl.cmd = XEN_SYSCTL_livepatch_op;
     sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST;
-    sysctl.u.livepatch.pad = 0;
-    sysctl.u.livepatch.u.list.version = 0;
     sysctl.u.livepatch.u.list.idx = start;
-    sysctl.u.livepatch.u.list.pad = 0;
 
     max_batch_sz = max;
-    /* Convience value. */
-    sz = sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE;
+    name_sz = name_total_size;
     *done = 0;
     *left = 0;
     do {
+        uint64_t _name_sz;
+
         /*
          * The first time we go in this loop our 'max' may be bigger
          * than what the hypervisor is comfortable with - hence the first
@@ -754,11 +801,11 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
         sysctl.u.livepatch.u.list.nr = nr;
         /* Fix the size (may vary between hypercalls). */
         HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info));
-        HYPERCALL_BOUNCE_SET_SIZE(name, nr * nr);
+        HYPERCALL_BOUNCE_SET_SIZE(name, name_sz);
         HYPERCALL_BOUNCE_SET_SIZE(len, nr * sizeof(*len));
         /* Move the pointer to proper offset into 'info'. */
         (HYPERCALL_BUFFER(info))->ubuf = info + *done;
-        (HYPERCALL_BUFFER(name))->ubuf = name + (sz * *done);
+        (HYPERCALL_BUFFER(name))->ubuf = name + name_off;
         (HYPERCALL_BUFFER(len))->ubuf = len + *done;
         /* Allocate memory. */
         rc = xc_hypercall_bounce_pre(xch, info);
@@ -827,14 +874,19 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
             break;
         }
         *left = sysctl.u.livepatch.u.list.nr; /* Total remaining count. */
+        _name_sz = sysctl.u.livepatch.u.list.name_total_size; /* Total received name size. */
         /* Copy only up 'rc' of data' - we could add 'min(rc,nr) if desired. */
         HYPERCALL_BOUNCE_SET_SIZE(info, (rc * sizeof(*info)));
-        HYPERCALL_BOUNCE_SET_SIZE(name, (rc * sz));
+        HYPERCALL_BOUNCE_SET_SIZE(name, _name_sz);
         HYPERCALL_BOUNCE_SET_SIZE(len, (rc * sizeof(*len)));
         /* Bounce the data and free the bounce buffer. */
         xc_hypercall_bounce_post(xch, info);
         xc_hypercall_bounce_post(xch, name);
         xc_hypercall_bounce_post(xch, len);
+
+        name_sz -= _name_sz;
+        name_off += _name_sz;
+
         /* And update how many elements of info we have copied into. */
         *done += rc;
         /* Update idx. */
diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
index a37b2457ff..8ac3d567fc 100644
--- a/tools/misc/xen-livepatch.c
+++ b/tools/misc/xen-livepatch.c
@@ -64,14 +64,14 @@ static const char *state2str(unsigned int state)
     return names[state];
 }
 
-/* This value was choosen adhoc. It could be 42 too. */
-#define MAX_LEN 11
 static int list_func(int argc, char *argv[])
 {
-    unsigned int idx, done, left, i;
+    unsigned int nr, done, left, i;
     xen_livepatch_status_t *info = NULL;
     char *name = NULL;
     uint32_t *len = NULL;
+    uint64_t name_total_size;
+    off_t name_off;
     int rc = ENOMEM;
 
     if ( argc )
@@ -79,65 +79,73 @@ static int list_func(int argc, char *argv[])
         show_help();
         return -1;
     }
-    idx = left = 0;
-    info = malloc(sizeof(*info) * MAX_LEN);
-    if ( !info )
-        return rc;
-    name = malloc(sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE * MAX_LEN);
-    if ( !name )
+    done = left = 0;
+
+    rc = xc_livepatch_list_get_sizes(xch, &nr, &name_total_size);
+    if ( rc )
     {
-        free(info);
+        rc = errno;
+        fprintf(stderr, "Failed to get list sizes.\n"
+                "Error %d: %s\n",
+                rc, strerror(rc));
         return rc;
     }
-    len = malloc(sizeof(*len) * MAX_LEN);
-    if ( !len ) {
-        free(name);
-        free(info);
+
+    if ( nr == 0 )
+    {
+        fprintf(stdout, "Nothing to list\n");
+        return 0;
+    }
+
+    info = malloc(nr * sizeof(*info));
+    if ( !info )
         return rc;
+
+    name = malloc(name_total_size * sizeof(*name));
+    if ( !name )
+        goto error_name;
+
+    len = malloc(nr * sizeof(*len));
+    if ( !len )
+        goto error_len;
+
+    memset(info, 'A', nr * sizeof(*info));
+    memset(name, 'B', name_total_size * sizeof(*name));
+    memset(len, 'C', nr * sizeof(*len));
+    name_off = 0;
+
+    rc = xc_livepatch_list(xch, nr, 0, info, name, len, name_total_size, &done, &left);
+    if ( rc || done != nr || left > 0)
+    {
+        rc = errno;
+        fprintf(stderr, "Failed to list %d/%d.\n"
+                "Error %d: %s\n",
+                left, nr, rc, strerror(rc));
+        goto error;
     }
 
-    do {
-        done = 0;
-        /* The memset is done to catch errors. */
-        memset(info, 'A', sizeof(*info) * MAX_LEN);
-        memset(name, 'B', sizeof(*name) * MAX_LEN * XEN_LIVEPATCH_NAME_SIZE);
-        memset(len, 'C', sizeof(*len) * MAX_LEN);
-        rc = xc_livepatch_list(xch, MAX_LEN, idx, info, name, len, &done, &left);
-        if ( rc )
-        {
-            rc = errno;
-            fprintf(stderr, "Failed to list %d/%d.\n"
-                            "Error %d: %s\n",
-                    idx, left, rc, strerror(rc));
-            break;
-        }
-        if ( !idx )
-            fprintf(stdout," ID                                     | status\n"
-                           "----------------------------------------+------------\n");
+    fprintf(stdout," ID                                     | status\n"
+                   "----------------------------------------+------------\n");
 
-        for ( i = 0; i < done; i++ )
-        {
-            unsigned int j;
-            uint32_t sz;
-            char *str;
-
-            sz = len[i];
-            str = name + (i * XEN_LIVEPATCH_NAME_SIZE);
-            for ( j = sz; j < XEN_LIVEPATCH_NAME_SIZE; j++ )
-                str[j] = '\0';
-
-            printf("%-40s| %s", str, state2str(info[i].state));
-            if ( info[i].rc )
-                printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc));
-            else
-                puts("");
-        }
-        idx += done;
-    } while ( left );
+    for ( i = 0; i < done; i++ )
+    {
+        char *name_str = name + name_off;
+
+        printf("%-40.*s| %s", len[i], name_str, state2str(info[i].state));
+        if ( info[i].rc )
+            printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc));
+        else
+            puts("");
+
+        name_off += len[i];
+    }
 
+error:
+    free(len);
+error_len:
     free(name);
+error_name:
     free(info);
-    free(len);
     return rc;
 }
 #undef MAX_LEN
diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index f88cf3bc73..f486cb3021 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -1163,7 +1163,6 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
 
     if ( list->nr &&
          (!guest_handle_okay(list->status, list->nr) ||
-          !guest_handle_okay(list->name, XEN_LIVEPATCH_NAME_SIZE * list->nr) ||
           !guest_handle_okay(list->len, list->nr)) )
         return -EINVAL;
 
@@ -1174,23 +1173,35 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
         return -EINVAL;
     }
 
+    list->name_total_size = 0;
     if ( list->nr )
     {
+        uint64_t name_offset = 0;
+
         list_for_each_entry( data, &payload_list, list )
         {
-            uint32_t len;
+            uint32_t name_len;
 
             if ( list->idx > i++ )
                 continue;
 
             status.state = data->state;
             status.rc = data->rc;
-            len = strlen(data->name) + 1;
+
+            name_len = strlen(data->name) + 1;
+            list->name_total_size += name_len;
+
+            if ( !guest_handle_subrange_okay(list->name, name_offset,
+                                             name_offset + name_len - 1) )
+            {
+                rc = -EINVAL;
+                break;
+            }
 
             /* N.B. 'idx' != 'i'. */
-            if ( __copy_to_guest_offset(list->name, idx * XEN_LIVEPATCH_NAME_SIZE,
-                                        data->name, len) ||
-                __copy_to_guest_offset(list->len, idx, &len, 1) ||
+            if ( __copy_to_guest_offset(list->name, name_offset,
+                                        data->name, name_len) ||
+                __copy_to_guest_offset(list->len, idx, &name_len, 1) ||
                 __copy_to_guest_offset(list->status, idx, &status, 1) )
             {
                 rc = -EFAULT;
@@ -1198,11 +1209,19 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
             }
 
             idx++;
+            name_offset += name_len;
 
             if ( (idx >= list->nr) || hypercall_preempt_check() )
                 break;
         }
     }
+    else
+    {
+        list_for_each_entry( data, &payload_list, list )
+        {
+            list->name_total_size += strlen(data->name) + 1;
+        }
+    }
     list->nr = payload_cnt - i; /* Remaining amount. */
     list->version = payload_version;
     spin_unlock(&payload_lock);
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 335e193712..b86804b7a6 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -926,10 +926,11 @@ struct xen_sysctl_livepatch_get {
  *
  * If the hypercall returns an positive number, it is the number (up to `nr`)
  * of the payloads returned, along with `nr` updated with the number of remaining
- * payloads, `version` updated (it may be the same across hypercalls. If it
- * varies the data is stale and further calls could fail). The `status`,
- * `name`, and `len`' are updated at their designed index value (`idx`) with
- * the returned value of data.
+ * payloads, `version` updated (it may be the same across hypercalls. If it varies
+ * the data is stale and further calls could fail) and the name_total_size
+ * containing total size of transfered data for the array.
+ * The `status`, `name`, `len` are updated at their designed index value (`idx`)
+ * with the returned value of data.
  *
  * If the hypercall returns E2BIG the `nr` is too big and should be
  * lowered. The upper limit of `nr` is left to the implemention.
@@ -952,11 +953,13 @@ struct xen_sysctl_livepatch_list {
                                                amount of payloads and version.
                                                OUT: How many payloads left. */
     uint32_t pad;                           /* IN: Must be zero. */
+    uint64_t name_total_size;               /* OUT: Total size of all transfer names */
     XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status;  /* OUT. Must have enough
                                                space allocate for nr of them. */
     XEN_GUEST_HANDLE_64(char) name;         /* OUT: Array of names. Each member
-                                               MUST XEN_LIVEPATCH_NAME_SIZE in size.
-                                               Must have nr of them. */
+                                               may have an arbitrary length up to
+                                               XEN_LIVEPATCH_NAME_SIZE bytes. Must have
+                                               nr of them. */
     XEN_GUEST_HANDLE_64(uint32) len;        /* OUT: Array of lengths of name's.
                                                Must have nr of them. */
 };
-- 
2.16.5




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

^ permalink raw reply related	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 11:27 [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation Pawel Wieczorkiewicz
@ 2019-08-15 11:38 ` Julien Grall
  2019-08-15 14:58   ` Lars Kurth
  0 siblings, 1 reply; 18+ messages in thread
From: Julien Grall @ 2019-08-15 11:38 UTC (permalink / raw)
  To: Pawel Wieczorkiewicz, xen-devel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, Tim Deegan, mpohlack,
	Ross Lagerwall, Jan Beulich, xen-devel

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 <wipawel@amazon.de>
> Reviewed-by: Andra-Irina Paraschiv <andraprs@amazon.com>
> Reviewed-by: Bjoern Doebel <doebel@amazon.de>
> Reviewed-by: Martin Pohlack <mpohlack@amazon.de>
> ---
>   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.
>    *
> - * It is expected that the caller of this function will take the
> - * 'left' and use the value for 'start'. This way we have an
> - * cursor in the array. Note that the 'info','name', and 'len' will
> - * be updated at the subsequent calls.
> + * It is expected that the caller of this function will first issue the
> + * xc_livepatch_list_get_sizes() in order to obtain total sizes of names
> + * as well as the current number of payload entries.
> + * The total sizes are required and supplied via the 'name_total_size'
> + * parameter.
>    *
> - * The 'max' is to be provided by the caller with the maximum
> - * number of entries that 'info', 'name', and 'len' arrays can
> - * be filled up with.
> - *
> - * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE
> - * length.
> + * The 'max' is to be provided by the caller with the maximum number of
> + * entries that 'info', 'name', 'len' arrays can be filled up with.
>    *
>    * Each entry in the 'info' array is expected to be of xen_livepatch_status_t
>    * structure size.
>    *
> + * Each entry in the 'name' array may have an arbitrary size.
> + *
>    * Each entry in the 'len' array is expected to be of uint32_t size.
>    *
>    * The return value is zero if the hypercall completed successfully.
> @@ -2597,10 +2614,12 @@ int xc_livepatch_get(xc_interface *xch,
>    * will contain the number of entries that had been succesfully
>    * retrieved (if any).
>    */
> -int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
> -                      xen_livepatch_status_t *info, char *name,
> -                      uint32_t *len, unsigned int *done,
> -                      unsigned int *left);
> +int xc_livepatch_list(xc_interface *xch, const unsigned int max,
> +                      const unsigned int start,
> +                      struct xen_livepatch_status *info,
> +                      char *name, uint32_t *len,
> +                      const uint64_t name_total_size,
> +                      unsigned int *done, unsigned int *left);
>   
>   /*
>    * The operations are asynchronous and the hypervisor may take a while
> diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
> index a8e9e7d1e2..d787f3f29f 100644
> --- a/tools/libxc/xc_misc.c
> +++ b/tools/libxc/xc_misc.c
> @@ -662,7 +662,48 @@ int xc_livepatch_get(xc_interface *xch,
>   }
>   
>   /*
> - * 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)
> +{
> +    DECLARE_SYSCTL;
> +    int rc;
> +
> +    if ( !nr || !name_total_size )
> +    {
> +        errno = EINVAL;
> +        return -1;
> +    }
> +
> +    memset(&sysctl, 0, sizeof(sysctl));
> +    sysctl.cmd = XEN_SYSCTL_livepatch_op;
> +    sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST;
> +
> +    rc = do_sysctl(xch, &sysctl);
> +    if ( rc )
> +        return rc;
> +
> +    *nr = sysctl.u.livepatch.u.list.nr;
> +    *name_total_size = sysctl.u.livepatch.u.list.name_total_size;
> +
> +    return 0;
> +}
> +
> +/*
> + * 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
> @@ -673,21 +714,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.
>    *
> - * It is expected that the caller of this function will take the
> - * 'left' and use the value for 'start'. This way we have an
> - * cursor in the array. Note that the 'info','name', and 'len' will
> - * be updated at the subsequent calls.
> + * It is expected that the caller of this function will first issue the
> + * xc_livepatch_list_get_sizes() in order to obtain total sizes of names
> + * as well as the current number of payload entries.
> + * The total sizes are required and supplied via the 'name_total_size'
> + * parameter.
>    *
> - * The 'max' is to be provided by the caller with the maximum
> - * number of entries that 'info', 'name', and 'len' arrays can
> - * be filled up with.
> - *
> - * Each entry in the 'name' array is expected to be of XEN_LIVEPATCH_NAME_SIZE
> - * length.
> + * The 'max' is to be provided by the caller with the maximum number of
> + * entries that 'info', 'name', 'len' arrays can be filled up with.
>    *
>    * Each entry in the 'info' array is expected to be of xen_livepatch_status_t
>    * structure size.
>    *
> + * Each entry in the 'name' array may have an arbitrary size.
> + *
>    * Each entry in the 'len' array is expected to be of uint32_t size.
>    *
>    * The return value is zero if the hypercall completed successfully.
> @@ -699,11 +739,12 @@ int xc_livepatch_get(xc_interface *xch,
>    * will contain the number of entries that had been succesfully
>    * retrieved (if any).
>    */
> -int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
> +int xc_livepatch_list(xc_interface *xch, const unsigned int max,
> +                      const unsigned int start,
>                         struct xen_livepatch_status *info,
>                         char *name, uint32_t *len,
> -                      unsigned int *done,
> -                      unsigned int *left)
> +                      const uint64_t name_total_size,
> +                      unsigned int *done, unsigned int *left)
>   {
>       int rc;
>       DECLARE_SYSCTL;
> @@ -714,27 +755,33 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
>       uint32_t max_batch_sz, nr;
>       uint32_t version = 0, retries = 0;
>       uint32_t adjust = 0;
> -    ssize_t sz;
> +    off_t name_off = 0;
> +    uint64_t name_sz;
>   
> -    if ( !max || !info || !name || !len )
> +    if ( !max || !info || !name || !len || !done || !left )
>       {
>           errno = EINVAL;
>           return -1;
>       }
>   
> +    if ( name_total_size == 0 )
> +    {
> +        errno = ENOENT;
> +        return -1;
> +    }
> +
> +    memset(&sysctl, 0, sizeof(sysctl));
>       sysctl.cmd = XEN_SYSCTL_livepatch_op;
>       sysctl.u.livepatch.cmd = XEN_SYSCTL_LIVEPATCH_LIST;
> -    sysctl.u.livepatch.pad = 0;
> -    sysctl.u.livepatch.u.list.version = 0;
>       sysctl.u.livepatch.u.list.idx = start;
> -    sysctl.u.livepatch.u.list.pad = 0;
>   
>       max_batch_sz = max;
> -    /* Convience value. */
> -    sz = sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE;
> +    name_sz = name_total_size;
>       *done = 0;
>       *left = 0;
>       do {
> +        uint64_t _name_sz;
> +
>           /*
>            * The first time we go in this loop our 'max' may be bigger
>            * than what the hypervisor is comfortable with - hence the first
> @@ -754,11 +801,11 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
>           sysctl.u.livepatch.u.list.nr = nr;
>           /* Fix the size (may vary between hypercalls). */
>           HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info));
> -        HYPERCALL_BOUNCE_SET_SIZE(name, nr * nr);
> +        HYPERCALL_BOUNCE_SET_SIZE(name, name_sz);
>           HYPERCALL_BOUNCE_SET_SIZE(len, nr * sizeof(*len));
>           /* Move the pointer to proper offset into 'info'. */
>           (HYPERCALL_BUFFER(info))->ubuf = info + *done;
> -        (HYPERCALL_BUFFER(name))->ubuf = name + (sz * *done);
> +        (HYPERCALL_BUFFER(name))->ubuf = name + name_off;
>           (HYPERCALL_BUFFER(len))->ubuf = len + *done;
>           /* Allocate memory. */
>           rc = xc_hypercall_bounce_pre(xch, info);
> @@ -827,14 +874,19 @@ int xc_livepatch_list(xc_interface *xch, unsigned int max, unsigned int start,
>               break;
>           }
>           *left = sysctl.u.livepatch.u.list.nr; /* Total remaining count. */
> +        _name_sz = sysctl.u.livepatch.u.list.name_total_size; /* Total received name size. */
>           /* Copy only up 'rc' of data' - we could add 'min(rc,nr) if desired. */
>           HYPERCALL_BOUNCE_SET_SIZE(info, (rc * sizeof(*info)));
> -        HYPERCALL_BOUNCE_SET_SIZE(name, (rc * sz));
> +        HYPERCALL_BOUNCE_SET_SIZE(name, _name_sz);
>           HYPERCALL_BOUNCE_SET_SIZE(len, (rc * sizeof(*len)));
>           /* Bounce the data and free the bounce buffer. */
>           xc_hypercall_bounce_post(xch, info);
>           xc_hypercall_bounce_post(xch, name);
>           xc_hypercall_bounce_post(xch, len);
> +
> +        name_sz -= _name_sz;
> +        name_off += _name_sz;
> +
>           /* And update how many elements of info we have copied into. */
>           *done += rc;
>           /* Update idx. */
> diff --git a/tools/misc/xen-livepatch.c b/tools/misc/xen-livepatch.c
> index a37b2457ff..8ac3d567fc 100644
> --- a/tools/misc/xen-livepatch.c
> +++ b/tools/misc/xen-livepatch.c
> @@ -64,14 +64,14 @@ static const char *state2str(unsigned int state)
>       return names[state];
>   }
>   
> -/* This value was choosen adhoc. It could be 42 too. */
> -#define MAX_LEN 11
>   static int list_func(int argc, char *argv[])
>   {
> -    unsigned int idx, done, left, i;
> +    unsigned int nr, done, left, i;
>       xen_livepatch_status_t *info = NULL;
>       char *name = NULL;
>       uint32_t *len = NULL;
> +    uint64_t name_total_size;
> +    off_t name_off;
>       int rc = ENOMEM;
>   
>       if ( argc )
> @@ -79,65 +79,73 @@ static int list_func(int argc, char *argv[])
>           show_help();
>           return -1;
>       }
> -    idx = left = 0;
> -    info = malloc(sizeof(*info) * MAX_LEN);
> -    if ( !info )
> -        return rc;
> -    name = malloc(sizeof(*name) * XEN_LIVEPATCH_NAME_SIZE * MAX_LEN);
> -    if ( !name )
> +    done = left = 0;
> +
> +    rc = xc_livepatch_list_get_sizes(xch, &nr, &name_total_size);
> +    if ( rc )
>       {
> -        free(info);
> +        rc = errno;
> +        fprintf(stderr, "Failed to get list sizes.\n"
> +                "Error %d: %s\n",
> +                rc, strerror(rc));
>           return rc;
>       }
> -    len = malloc(sizeof(*len) * MAX_LEN);
> -    if ( !len ) {
> -        free(name);
> -        free(info);
> +
> +    if ( nr == 0 )
> +    {
> +        fprintf(stdout, "Nothing to list\n");
> +        return 0;
> +    }
> +
> +    info = malloc(nr * sizeof(*info));
> +    if ( !info )
>           return rc;
> +
> +    name = malloc(name_total_size * sizeof(*name));
> +    if ( !name )
> +        goto error_name;
> +
> +    len = malloc(nr * sizeof(*len));
> +    if ( !len )
> +        goto error_len;
> +
> +    memset(info, 'A', nr * sizeof(*info));
> +    memset(name, 'B', name_total_size * sizeof(*name));
> +    memset(len, 'C', nr * sizeof(*len));
> +    name_off = 0;
> +
> +    rc = xc_livepatch_list(xch, nr, 0, info, name, len, name_total_size, &done, &left);
> +    if ( rc || done != nr || left > 0)
> +    {
> +        rc = errno;
> +        fprintf(stderr, "Failed to list %d/%d.\n"
> +                "Error %d: %s\n",
> +                left, nr, rc, strerror(rc));
> +        goto error;
>       }
>   
> -    do {
> -        done = 0;
> -        /* The memset is done to catch errors. */
> -        memset(info, 'A', sizeof(*info) * MAX_LEN);
> -        memset(name, 'B', sizeof(*name) * MAX_LEN * XEN_LIVEPATCH_NAME_SIZE);
> -        memset(len, 'C', sizeof(*len) * MAX_LEN);
> -        rc = xc_livepatch_list(xch, MAX_LEN, idx, info, name, len, &done, &left);
> -        if ( rc )
> -        {
> -            rc = errno;
> -            fprintf(stderr, "Failed to list %d/%d.\n"
> -                            "Error %d: %s\n",
> -                    idx, left, rc, strerror(rc));
> -            break;
> -        }
> -        if ( !idx )
> -            fprintf(stdout," ID                                     | status\n"
> -                           "----------------------------------------+------------\n");
> +    fprintf(stdout," ID                                     | status\n"
> +                   "----------------------------------------+------------\n");
>   
> -        for ( i = 0; i < done; i++ )
> -        {
> -            unsigned int j;
> -            uint32_t sz;
> -            char *str;
> -
> -            sz = len[i];
> -            str = name + (i * XEN_LIVEPATCH_NAME_SIZE);
> -            for ( j = sz; j < XEN_LIVEPATCH_NAME_SIZE; j++ )
> -                str[j] = '\0';
> -
> -            printf("%-40s| %s", str, state2str(info[i].state));
> -            if ( info[i].rc )
> -                printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc));
> -            else
> -                puts("");
> -        }
> -        idx += done;
> -    } while ( left );
> +    for ( i = 0; i < done; i++ )
> +    {
> +        char *name_str = name + name_off;
> +
> +        printf("%-40.*s| %s", len[i], name_str, state2str(info[i].state));
> +        if ( info[i].rc )
> +            printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc));
> +        else
> +            puts("");
> +
> +        name_off += len[i];
> +    }
>   
> +error:
> +    free(len);
> +error_len:
>       free(name);
> +error_name:
>       free(info);
> -    free(len);
>       return rc;
>   }
>   #undef MAX_LEN
> diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> index f88cf3bc73..f486cb3021 100644
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -1163,7 +1163,6 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>   
>       if ( list->nr &&
>            (!guest_handle_okay(list->status, list->nr) ||
> -          !guest_handle_okay(list->name, XEN_LIVEPATCH_NAME_SIZE * list->nr) ||
>             !guest_handle_okay(list->len, list->nr)) )
>           return -EINVAL;
>   
> @@ -1174,23 +1173,35 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>           return -EINVAL;
>       }
>   
> +    list->name_total_size = 0;
>       if ( list->nr )
>       {
> +        uint64_t name_offset = 0;
> +
>           list_for_each_entry( data, &payload_list, list )
>           {
> -            uint32_t len;
> +            uint32_t name_len;
>   
>               if ( list->idx > i++ )
>                   continue;
>   
>               status.state = data->state;
>               status.rc = data->rc;
> -            len = strlen(data->name) + 1;
> +
> +            name_len = strlen(data->name) + 1;
> +            list->name_total_size += name_len;
> +
> +            if ( !guest_handle_subrange_okay(list->name, name_offset,
> +                                             name_offset + name_len - 1) )
> +            {
> +                rc = -EINVAL;
> +                break;
> +            }
>   
>               /* N.B. 'idx' != 'i'. */
> -            if ( __copy_to_guest_offset(list->name, idx * XEN_LIVEPATCH_NAME_SIZE,
> -                                        data->name, len) ||
> -                __copy_to_guest_offset(list->len, idx, &len, 1) ||
> +            if ( __copy_to_guest_offset(list->name, name_offset,
> +                                        data->name, name_len) ||
> +                __copy_to_guest_offset(list->len, idx, &name_len, 1) ||
>                   __copy_to_guest_offset(list->status, idx, &status, 1) )
>               {
>                   rc = -EFAULT;
> @@ -1198,11 +1209,19 @@ static int livepatch_list(struct xen_sysctl_livepatch_list *list)
>               }
>   
>               idx++;
> +            name_offset += name_len;
>   
>               if ( (idx >= list->nr) || hypercall_preempt_check() )
>                   break;
>           }
>       }
> +    else
> +    {
> +        list_for_each_entry( data, &payload_list, list )
> +        {
> +            list->name_total_size += strlen(data->name) + 1;
> +        }
> +    }
>       list->nr = payload_cnt - i; /* Remaining amount. */
>       list->version = payload_version;
>       spin_unlock(&payload_lock);
> diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
> index 335e193712..b86804b7a6 100644
> --- a/xen/include/public/sysctl.h
> +++ b/xen/include/public/sysctl.h
> @@ -926,10 +926,11 @@ struct xen_sysctl_livepatch_get {
>    *
>    * If the hypercall returns an positive number, it is the number (up to `nr`)
>    * of the payloads returned, along with `nr` updated with the number of remaining
> - * payloads, `version` updated (it may be the same across hypercalls. If it
> - * varies the data is stale and further calls could fail). The `status`,
> - * `name`, and `len`' are updated at their designed index value (`idx`) with
> - * the returned value of data.
> + * payloads, `version` updated (it may be the same across hypercalls. If it varies
> + * the data is stale and further calls could fail) and the name_total_size
> + * containing total size of transfered data for the array.
> + * The `status`, `name`, `len` are updated at their designed index value (`idx`)
> + * with the returned value of data.
>    *
>    * If the hypercall returns E2BIG the `nr` is too big and should be
>    * lowered. The upper limit of `nr` is left to the implemention.
> @@ -952,11 +953,13 @@ struct xen_sysctl_livepatch_list {
>                                                  amount of payloads and version.
>                                                  OUT: How many payloads left. */
>       uint32_t pad;                           /* IN: Must be zero. */
> +    uint64_t name_total_size;               /* OUT: Total size of all transfer names */
>       XEN_GUEST_HANDLE_64(xen_livepatch_status_t) status;  /* OUT. Must have enough
>                                                  space allocate for nr of them. */
>       XEN_GUEST_HANDLE_64(char) name;         /* OUT: Array of names. Each member
> -                                               MUST XEN_LIVEPATCH_NAME_SIZE in size.
> -                                               Must have nr of them. */
> +                                               may have an arbitrary length up to
> +                                               XEN_LIVEPATCH_NAME_SIZE bytes. Must have
> +                                               nr of them. */
>       XEN_GUEST_HANDLE_64(uint32) len;        /* OUT: Array of lengths of name's.
>                                                  Must have nr of them. */
>   };
> 

-- 
Julien Grall

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 11:38 ` Julien Grall
@ 2019-08-15 14:58   ` Lars Kurth
  2019-08-15 15:19     ` Wieczorkiewicz, Pawel
  0 siblings, 1 reply; 18+ messages in thread
From: Lars Kurth @ 2019-08-15 14:58 UTC (permalink / raw)
  To: Julien Grall, Pawel Wieczorkiewicz
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, mpohlack,
	Ross Lagerwall, 'Jan Beulich',
	xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2556 bytes --]



> On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@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 <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 <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 <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 <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 <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




[-- Attachment #1.2: Type: text/html, Size: 11557 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 14:58   ` Lars Kurth
@ 2019-08-15 15:19     ` Wieczorkiewicz, Pawel
  2019-08-15 15:29       ` Julien Grall
  2019-08-15 15:33       ` Lars Kurth
  0 siblings, 2 replies; 18+ messages in thread
From: Wieczorkiewicz, Pawel @ 2019-08-15 15:19 UTC (permalink / raw)
  To: Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ross Lagerwall, Ian Jackson,
	xen-devel, Pohlack, Martin, Wieczorkiewicz, Pawel, Julien Grall,
	Jan Beulich, xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2877 bytes --]

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 <lars.kurth.xen@gmail.com<mailto:lars.kurth.xen@gmail.com>> wrote:



On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com<mailto:julien.grall@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



[-- Attachment #1.2: Type: text/html, Size: 13738 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:19     ` Wieczorkiewicz, Pawel
@ 2019-08-15 15:29       ` Julien Grall
  2019-08-15 15:32         ` George Dunlap
  2019-08-15 15:42         ` Wieczorkiewicz, Pawel
  2019-08-15 15:33       ` Lars Kurth
  1 sibling, 2 replies; 18+ messages in thread
From: Julien Grall @ 2019-08-15 15:29 UTC (permalink / raw)
  To: Wieczorkiewicz, Pawel, Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Jan Beulich, xen-devel



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 <lars.kurth.xen@gmail.com 
>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>
>>
>>
>>> On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com 
>>> <mailto:julien.grall@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

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:29       ` Julien Grall
@ 2019-08-15 15:32         ` George Dunlap
  2019-08-15 15:36           ` Julien Grall
  2019-08-15 15:42         ` Wieczorkiewicz, Pawel
  1 sibling, 1 reply; 18+ messages in thread
From: George Dunlap @ 2019-08-15 15:32 UTC (permalink / raw)
  To: Julien Grall, Wieczorkiewicz, Pawel, Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Jan Beulich, xen-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:19     ` Wieczorkiewicz, Pawel
  2019-08-15 15:29       ` Julien Grall
@ 2019-08-15 15:33       ` Lars Kurth
  2019-08-15 15:46         ` Lars Kurth
  1 sibling, 1 reply; 18+ messages in thread
From: Lars Kurth @ 2019-08-15 15:33 UTC (permalink / raw)
  To: Wieczorkiewicz, Pawel
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Julien Grall, 'Jan Beulich',
	xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 4994 bytes --]



> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de> 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://patchew.org/Xen/>, https://patchwork.kernel.org/project/xen-devel/list/ <https://patchwork.kernel.org/project/xen-devel/list/> or https://lore.kernel.org/xen-devel/ <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 <lars.kurth.xen@gmail.com <mailto:lars.kurth.xen@gmail.com>> wrote:
>> 
>> 
>> 
>>> On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com <mailto:julien.grall@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 <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 <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 <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 <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 <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 
> 
> 


[-- Attachment #1.2: Type: text/html, Size: 16480 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:32         ` George Dunlap
@ 2019-08-15 15:36           ` Julien Grall
  2019-08-15 15:48             ` George Dunlap
  0 siblings, 1 reply; 18+ messages in thread
From: Julien Grall @ 2019-08-15 15:36 UTC (permalink / raw)
  To: George Dunlap, Wieczorkiewicz, Pawel, Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Jan Beulich, xen-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:29       ` Julien Grall
  2019-08-15 15:32         ` George Dunlap
@ 2019-08-15 15:42         ` Wieczorkiewicz, Pawel
  2019-08-15 16:29           ` Andrew Cooper
  1 sibling, 1 reply; 18+ messages in thread
From: Wieczorkiewicz, Pawel @ 2019-08-15 15:42 UTC (permalink / raw)
  To: Julien Grall
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk, Lars Kurth,
	Andrew Cooper, Ross Lagerwall, Ian Jackson, George Dunlap,
	xen-devel, Pohlack, Martin, Wieczorkiewicz, Pawel, Jan Beulich,
	xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 4168 bytes --]

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 <julien.grall@arm.com<mailto:julien.grall@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 <lars.kurth.xen@gmail.com<mailto:lars.kurth.xen@gmail.com> <mailto:lars.kurth.xen@gmail.com>> wrote:



On 15 Aug 2019, at 12:38, Julien Grall <julien.grall@arm.com<mailto:julien.grall@arm.com> <mailto:julien.grall@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



[-- Attachment #1.2: Type: text/html, Size: 7560 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:33       ` Lars Kurth
@ 2019-08-15 15:46         ` Lars Kurth
  2019-08-15 15:58           ` Julien Grall
  0 siblings, 1 reply; 18+ messages in thread
From: Lars Kurth @ 2019-08-15 15:46 UTC (permalink / raw)
  To: Wieczorkiewicz, Pawel
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Julien Grall, 'Jan Beulich',
	xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2154 bytes --]



> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@gmail.com> wrote:
> 
> 
> 
>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de <mailto:wipawel@amazon.de>> 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



[-- Attachment #1.2: Type: text/html, Size: 5132 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:36           ` Julien Grall
@ 2019-08-15 15:48             ` George Dunlap
  2019-08-15 16:00               ` Julien Grall
  0 siblings, 1 reply; 18+ messages in thread
From: George Dunlap @ 2019-08-15 15:48 UTC (permalink / raw)
  To: Julien Grall, Wieczorkiewicz, Pawel, Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Jan Beulich, xen-devel

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 / &c).

 -George

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:46         ` Lars Kurth
@ 2019-08-15 15:58           ` Julien Grall
  2019-08-15 16:17             ` Lars Kurth
  0 siblings, 1 reply; 18+ messages in thread
From: Julien Grall @ 2019-08-15 15:58 UTC (permalink / raw)
  To: Lars Kurth, Wieczorkiewicz, Pawel
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, 'Jan Beulich',
	xen-devel

Hi Lars,

On 15/08/2019 16:46, Lars Kurth wrote:
> 
> 
>> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@gmail.com 
>> <mailto:lars.kurth.xen@gmail.com>> wrote:
>>
>>
>>
>>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de 
>>> <mailto:wipawel@amazon.de>> 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 
> <mailto: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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:48             ` George Dunlap
@ 2019-08-15 16:00               ` Julien Grall
  2019-08-15 16:23                 ` George Dunlap
  0 siblings, 1 reply; 18+ messages in thread
From: Julien Grall @ 2019-08-15 16:00 UTC (permalink / raw)
  To: George Dunlap, Wieczorkiewicz, Pawel, Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Jan Beulich, xen-devel

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 / &c).

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:58           ` Julien Grall
@ 2019-08-15 16:17             ` Lars Kurth
  0 siblings, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2019-08-15 16:17 UTC (permalink / raw)
  To: Julien Grall
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ross Lagerwall, Ian Jackson,
	xen-devel, Pohlack, Martin, Wieczorkiewicz, Pawel,
	'Jan Beulich',
	xen-devel



> On 15 Aug 2019, at 16:58, Julien Grall <julien.grall@arm.com> wrote:
> 
> Hi Lars,
> 
> On 15/08/2019 16:46, Lars Kurth wrote:
>>> On 15 Aug 2019, at 16:33, Lars Kurth <lars.kurth.xen@gmail.com <mailto:lars.kurth.xen@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>>> On 15 Aug 2019, at 16:19, Wieczorkiewicz, Pawel <wipawel@amazon.de <mailto:wipawel@amazon.de>> 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 <mailto: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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 16:00               ` Julien Grall
@ 2019-08-15 16:23                 ` George Dunlap
  0 siblings, 0 replies; 18+ messages in thread
From: George Dunlap @ 2019-08-15 16:23 UTC (permalink / raw)
  To: Julien Grall, Wieczorkiewicz, Pawel, Lars Kurth
  Cc: Tim (Xen.org),
	Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Andrew Cooper, Ian Jackson, xen-devel, Pohlack,
	Martin, Ross Lagerwall, Jan Beulich, xen-devel

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 / &c).
> 
> 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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 15:42         ` Wieczorkiewicz, Pawel
@ 2019-08-15 16:29           ` Andrew Cooper
  2019-08-15 18:59             ` Lars Kurth
  2019-08-21 18:38             ` Konrad Rzeszutek Wilk
  0 siblings, 2 replies; 18+ messages in thread
From: Andrew Cooper @ 2019-08-15 16:29 UTC (permalink / raw)
  To: Wieczorkiewicz, Pawel, Julien Grall
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk, Lars Kurth,
	Tim (Xen.org),
	Ross Lagerwall, Ian Jackson, xen-devel, Pohlack, Martin,
	George Dunlap, Jan Beulich, xen-devel

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 <xen-devel@lists.xenproject.org>
sendemail.from= $ME <$ME@example.com>

Second, render the patch series:

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

$ $EDITOR 0000-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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 16:29           ` Andrew Cooper
@ 2019-08-15 18:59             ` Lars Kurth
  2019-08-21 18:38             ` Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 18+ messages in thread
From: Lars Kurth @ 2019-08-15 18:59 UTC (permalink / raw)
  To: Andrew Cooper, Wieczorkiewicz, Pawel
  Cc: Stefano Stabellini, Wei Liu, Konrad Rzeszutek Wilk,
	George Dunlap, Tim (Xen.org),
	Ian Jackson, xen-devel, Pohlack, Martin, Ross Lagerwall,
	Julien Grall, 'Jan Beulich',
	xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2821 bytes --]



> On 15 Aug 2019, at 17:29, Andrew Cooper <andrew.cooper3@citrix.com> 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 <xen-devel@lists.xenproject.org>
> sendemail.from= $ME <$ME@example.com>
> 
> Second, render the patch series:
> 
> $ mkdir foo-v1
> $ cd foo-v1
> $ git format-patch master --cover-letter
> 0000-cover-letter.patch
> 0001- ....
> ....
> 
> $ $EDITOR 0000-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/msg01575.html>
https://lists.xenproject.org/archives/html/xen-devel/2019-08/msg01581.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 <https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#Using_add_maintainers.pl_.28or_get_maintainer.pl.29_from_outside_of_xen.git>

Lars


[-- Attachment #1.2: Type: text/html, Size: 4422 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation
  2019-08-15 16:29           ` Andrew Cooper
  2019-08-15 18:59             ` Lars Kurth
@ 2019-08-21 18:38             ` Konrad Rzeszutek Wilk
  1 sibling, 0 replies; 18+ messages in thread
From: Konrad Rzeszutek Wilk @ 2019-08-21 18:38 UTC (permalink / raw)
  To: Andrew Cooper, Wieczorkiewicz, Pawel, Julien Grall
  Cc: Stefano Stabellini, Wei Liu, Ross Lagerwall, Lars Kurth,
	Tim (Xen.org),
	Ian Jackson, xen-devel, Pohlack, Martin, George Dunlap,
	Jan Beulich, xen-devel

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2019-08-21 18:39 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-15 11:27 [Xen-devel] [PATCH lp-metadata 2/3] livepatch: Handle arbitrary size names with the list operation Pawel Wieczorkiewicz
2019-08-15 11:38 ` Julien Grall
2019-08-15 14:58   ` Lars Kurth
2019-08-15 15:19     ` Wieczorkiewicz, Pawel
2019-08-15 15:29       ` Julien Grall
2019-08-15 15:32         ` George Dunlap
2019-08-15 15:36           ` Julien Grall
2019-08-15 15:48             ` George Dunlap
2019-08-15 16:00               ` Julien Grall
2019-08-15 16:23                 ` George Dunlap
2019-08-15 15:42         ` Wieczorkiewicz, Pawel
2019-08-15 16:29           ` Andrew Cooper
2019-08-15 18:59             ` Lars Kurth
2019-08-21 18:38             ` Konrad Rzeszutek Wilk
2019-08-15 15:33       ` Lars Kurth
2019-08-15 15:46         ` Lars Kurth
2019-08-15 15:58           ` Julien Grall
2019-08-15 16:17             ` Lars Kurth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).