All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
@ 2015-10-06 11:35 Juergen Gross
  2015-10-06 12:52 ` Andrew Cooper
  0 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2015-10-06 11:35 UTC (permalink / raw)
  To: xen-devel, Ian.Campbell, ian.jackson, stefano.stabellini, wei.liu2
  Cc: Juergen Gross

In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
being used by an in-tree component (qemu-xen). All other functions are
superfluous wrappers of the domain builder which can be removed.

Suggested-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
---
 tools/libxc/include/xenguest.h    |  52 --------------
 tools/libxc/xc_dom_compat_linux.c | 142 +++++---------------------------------
 tools/libxl/libxl_arch.h          |   2 +
 3 files changed, 20 insertions(+), 176 deletions(-)

diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 1a1a185..0a8d6e5 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -151,54 +151,6 @@ int xc_linux_build(xc_interface *xch,
                    unsigned int console_evtchn,
                    unsigned long *console_mfn);
 
-/** The same interface, but the dom structure is managed by the caller */
-struct xc_dom_image;
-int xc_dom_linux_build(xc_interface *xch,
-		       struct xc_dom_image *dom,
-		       uint32_t domid,
-		       unsigned int mem_mb,
-		       const char *image_name,
-		       const char *ramdisk_name,
-		       unsigned long flags,
-		       unsigned int store_evtchn,
-		       unsigned long *store_mfn,
-		       unsigned int console_evtchn,
-		       unsigned long *console_mfn);
-
-/**
- * This function will create a domain for a paravirtualized Linux
- * using buffers for kernel and initrd
- *
- * @parm xch a handle to an open hypervisor interface
- * @parm domid the id of the domain
- * @parm mem_mb memory size in megabytes
- * @parm image_buffer buffer containing kernel image
- * @parm image_size size of the kernel image buffer
- * @parm initrd_buffer name of the ramdisk image file
- * @parm initrd_size size of the ramdisk buffer
- * @parm cmdline command line string
- * @parm flags domain creation flags
- * @parm store_evtchn the store event channel for this domain to use
- * @parm store_mfn returned with the mfn of the store page
- * @parm console_evtchn the console event channel for this domain to use
- * @parm conole_mfn returned with the mfn of the console page
- * @return 0 on success, -1 on failure
- */
-int xc_linux_build_mem(xc_interface *xch,
-                       uint32_t domid,
-                       unsigned int mem_mb,
-                       const char *image_buffer,
-                       unsigned long image_size,
-                       const char *initrd_buffer,
-                       unsigned long initrd_size,
-                       const char *cmdline,
-                       const char *features,
-                       unsigned long flags,
-                       unsigned int store_evtchn,
-                       unsigned long *store_mfn,
-                       unsigned int console_evtchn,
-                       unsigned long *console_mfn);
-
 struct xc_hvm_firmware_module {
     uint8_t  *data;
     uint32_t  length;
@@ -276,10 +228,6 @@ int xc_await_suspend(xc_interface *xch, xc_evtchn *xce, int suspend_evtchn);
 int xc_suspend_evtchn_init_sane(xc_interface *xch, xc_evtchn *xce,
                                 int domid, int port, int *lockfd);
 
-int xc_get_bit_size(xc_interface *xch,
-                    const char *image_name, const char *cmdline,
-                    const char *features, int *type);
-
 int xc_mark_page_online(xc_interface *xch, unsigned long start,
                         unsigned long end, uint32_t *status);
 
diff --git a/tools/libxc/xc_dom_compat_linux.c b/tools/libxc/xc_dom_compat_linux.c
index a3abb99..105b1a8 100644
--- a/tools/libxc/xc_dom_compat_linux.c
+++ b/tools/libxc/xc_dom_compat_linux.c
@@ -34,79 +34,6 @@
 
 /* ------------------------------------------------------------------------ */
 
-static int xc_linux_build_internal(struct xc_dom_image *dom,
-                                   xc_interface *xch, uint32_t domid,
-                                   unsigned int mem_mb,
-                                   unsigned long flags,
-                                   unsigned int store_evtchn,
-                                   unsigned long *store_mfn,
-                                   unsigned int console_evtchn,
-                                   unsigned long *console_mfn)
-{
-    int rc;
-
-    dom->flags = flags;
-    dom->console_evtchn = console_evtchn;
-    dom->xenstore_evtchn = store_evtchn;
-
-    if ( (rc = xc_dom_boot_xen_init(dom, xch, domid)) != 0 )
-        goto out;
-    if ( (rc = xc_dom_parse_image(dom)) != 0 )
-        goto out;
-    if ( (rc = xc_dom_mem_init(dom, mem_mb)) != 0 )
-        goto out;
-    if ( (rc = xc_dom_boot_mem_init(dom)) != 0 )
-        goto out;
-    if ( (rc = xc_dom_build_image(dom)) != 0 )
-        goto out;
-    if ( (rc = xc_dom_boot_image(dom)) != 0 )
-        goto out;
-    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
-        goto out;
-
-    *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
-    *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
-
- out:
-    return rc;
-}
-
-int xc_linux_build_mem(xc_interface *xch, uint32_t domid,
-                       unsigned int mem_mb,
-                       const char *image_buffer,
-                       unsigned long image_size,
-                       const char *initrd,
-                       unsigned long initrd_len,
-                       const char *cmdline,
-                       const char *features,
-                       unsigned long flags,
-                       unsigned int store_evtchn,
-                       unsigned long *store_mfn,
-                       unsigned int console_evtchn,
-                       unsigned long *console_mfn)
-{
-    struct xc_dom_image *dom;
-    int rc;
-
-    xc_dom_loginit(xch);
-    dom = xc_dom_allocate(xch, cmdline, features);
-    if (dom == NULL)
-        return -1;
-    if ( (rc = xc_dom_kernel_mem(dom, image_buffer, image_size)) != 0 )
-        goto out;
-    if ( initrd && ((rc = xc_dom_ramdisk_mem(dom, initrd, initrd_len)) != 0) )
-        goto out;
-
-    rc = xc_linux_build_internal(dom, xch, domid,
-                                 mem_mb, flags,
-                                 store_evtchn, store_mfn,
-                                 console_evtchn, console_mfn);
-
- out:
-    xc_dom_release(dom);
-    return rc;
-}
-
 int xc_linux_build(xc_interface *xch, uint32_t domid,
                    unsigned int mem_mb,
                    const char *image_name,
@@ -132,66 +59,33 @@ int xc_linux_build(xc_interface *xch, uint32_t domid,
          ((rc = xc_dom_ramdisk_file(dom, initrd_name)) != 0) )
         goto out;
 
-    rc = xc_linux_build_internal(dom, xch, domid,
-                                 mem_mb, flags,
-                                 store_evtchn, store_mfn,
-                                 console_evtchn, console_mfn);
+    dom->flags = flags;
+    dom->console_evtchn = console_evtchn;
+    dom->xenstore_evtchn = store_evtchn;
 
- out:
-    xc_dom_release(dom);
-    return rc;
-}
-int xc_get_bit_size(xc_interface *xch,
-                    const char *image_name, const char *cmdline, 
-                    const char *features, int *bit_size)
-{
-    struct xc_dom_image *dom;
-    int rc;
-    *bit_size = 0;
-    dom = xc_dom_allocate(xch, cmdline, features);
-    if (dom == NULL)
-        return -1;
-    if ( (rc = xc_dom_kernel_file(dom, image_name)) != 0 )
+    if ( (rc = xc_dom_boot_xen_init(dom, xch, domid)) != 0 )
         goto out;
     if ( (rc = xc_dom_parse_image(dom)) != 0 )
         goto out;
-    if( dom->guest_type != NULL){
-        if(strstr(dom->guest_type, "x86_64") != NULL)
-            *bit_size = X86_64_B_SIZE; //64bit Guest 
-        if(strstr(dom->guest_type, "x86_32") != NULL)
-            *bit_size = X86_32_B_SIZE; //32bit Guest
-    }
+    if ( (rc = xc_dom_mem_init(dom, mem_mb)) != 0 )
+        goto out;
+    if ( (rc = xc_dom_boot_mem_init(dom)) != 0 )
+        goto out;
+    if ( (rc = xc_dom_build_image(dom)) != 0 )
+        goto out;
+    if ( (rc = xc_dom_boot_image(dom)) != 0 )
+        goto out;
+    if ( (rc = xc_dom_gnttab_init(dom)) != 0)
+        goto out;
+
+    *console_mfn = xc_dom_p2m_host(dom, dom->console_pfn);
+    *store_mfn = xc_dom_p2m_host(dom, dom->xenstore_pfn);
 
-out:
+ out:
     xc_dom_release(dom);
     return rc;
 }
 
-int xc_dom_linux_build(xc_interface *xch,
-                       struct xc_dom_image *dom,
-                       uint32_t domid,
-                       unsigned int mem_mb,
-                       const char *image_name,
-                       const char *initrd_name,
-                       unsigned long flags,
-                       unsigned int store_evtchn,
-                       unsigned long *store_mfn,
-                       unsigned int console_evtchn, unsigned long *console_mfn)
-{
-    int rc;
-
-    if ( (rc = xc_dom_kernel_file(dom, image_name)) != 0 )
-        return rc;
-    if ( initrd_name && strlen(initrd_name) &&
-         ((rc = xc_dom_ramdisk_file(dom, initrd_name)) != 0) )
-        return rc;
-
-    return xc_linux_build_internal(dom, xch, domid,
-                                   mem_mb, flags,
-                                   store_evtchn, store_mfn,
-                                   console_evtchn, console_mfn);
-}
-
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_arch.h b/tools/libxl/libxl_arch.h
index bd030b6..55e3513 100644
--- a/tools/libxl/libxl_arch.h
+++ b/tools/libxl/libxl_arch.h
@@ -15,6 +15,8 @@
 #ifndef LIBXL_ARCH_H
 #define LIBXL_ARCH_H
 
+struct xc_dom_image;
+
 /* fill the arch specific configuration for the domain */
 _hidden
 int libxl__arch_domain_prepare_config(libxl__gc *gc,
-- 
2.1.4

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-06 11:35 [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c Juergen Gross
@ 2015-10-06 12:52 ` Andrew Cooper
  2015-10-06 12:58   ` Wei Liu
  0 siblings, 1 reply; 14+ messages in thread
From: Andrew Cooper @ 2015-10-06 12:52 UTC (permalink / raw)
  To: Juergen Gross, xen-devel, Ian.Campbell, ian.jackson,
	stefano.stabellini, wei.liu2

On 06/10/15 12:35, Juergen Gross wrote:
> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
> being used by an in-tree component (qemu-xen). All other functions are
> superfluous wrappers of the domain builder which can be removed.
>
> Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>

Sorry, but NACK.  They are *not* superfluous.

XenServer uses them; xc_dom_linux_build() is the only way to apply
XSA-25 size restrictions to PV kernels and initrds.

~Andrew

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-06 12:52 ` Andrew Cooper
@ 2015-10-06 12:58   ` Wei Liu
  2015-10-06 13:06     ` Andrew Cooper
  0 siblings, 1 reply; 14+ messages in thread
From: Wei Liu @ 2015-10-06 12:58 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Juergen Gross, wei.liu2, Ian.Campbell, stefano.stabellini,
	ian.jackson, xen-devel

On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
> On 06/10/15 12:35, Juergen Gross wrote:
> > In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
> > being used by an in-tree component (qemu-xen). All other functions are
> > superfluous wrappers of the domain builder which can be removed.
> >
> > Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> > Signed-off-by: Juergen Gross <jgross@suse.com>
> 
> Sorry, but NACK.  They are *not* superfluous.
> 
> XenServer uses them; xc_dom_linux_build() is the only way to apply
> XSA-25 size restrictions to PV kernels and initrds.
> 

Could you explain a bit more about this? How could this particular
function apply restrictions?

Unfortunately XSA-25 is not on XSA page so I have no idea what that is.

Wei.

> ~Andrew

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-06 12:58   ` Wei Liu
@ 2015-10-06 13:06     ` Andrew Cooper
  2015-10-06 13:17       ` Ian Campbell
  0 siblings, 1 reply; 14+ messages in thread
From: Andrew Cooper @ 2015-10-06 13:06 UTC (permalink / raw)
  To: Wei Liu
  Cc: Juergen Gross, stefano.stabellini, ian.jackson, Ian.Campbell, xen-devel

On 06/10/15 13:58, Wei Liu wrote:
> On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
>> On 06/10/15 12:35, Juergen Gross wrote:
>>> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is currently
>>> being used by an in-tree component (qemu-xen). All other functions are
>>> superfluous wrappers of the domain builder which can be removed.
>>>
>>> Suggested-by: Ian Campbell <ian.campbell@citrix.com>
>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>> Sorry, but NACK.  They are *not* superfluous.
>>
>> XenServer uses them; xc_dom_linux_build() is the only way to apply
>> XSA-25 size restrictions to PV kernels and initrds.
>>
> Could you explain a bit more about this? How could this particular
> function apply restrictions?
>
> Unfortunately XSA-25 is not on XSA page so I have no idea what that is.
>
> Wei.

Older XSAs are listed on the wiki
http://wiki.xen.org/wiki/Security_Announcements

XSA-25 introduced xc_dom_{kernel,ramdisk}_max_size() to set upper
decompression limits on the kernel and initrd.

To use them, a struct xc_dom_image *dom is needed, which means the only
safe way of constructing PV domains is

xc_dom_allocate()
xc_dom_kernel_max_size()
xc_dom_ramdisk_max_size()
xc_dom_linux_build()

To have the decompression limits in place before decompression starts.

~Andrew

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-06 13:06     ` Andrew Cooper
@ 2015-10-06 13:17       ` Ian Campbell
  2015-10-19 10:36         ` Juergen Gross
  2015-10-22 15:21         ` Wei Liu
  0 siblings, 2 replies; 14+ messages in thread
From: Ian Campbell @ 2015-10-06 13:17 UTC (permalink / raw)
  To: Andrew Cooper, Wei Liu
  Cc: Juergen Gross, stefano.stabellini, ian.jackson, xen-devel

On Tue, 2015-10-06 at 14:06 +0100, Andrew Cooper wrote:
> On 06/10/15 13:58, Wei Liu wrote:
> > On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
> > > On 06/10/15 12:35, Juergen Gross wrote:
> > > > In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is
> > > > currently
> > > > being used by an in-tree component (qemu-xen). All other functions
> > > > are
> > > > superfluous wrappers of the domain builder which can be removed.
> > > > 
> > > > Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> > > > Signed-off-by: Juergen Gross <jgross@suse.com>
> > > Sorry, but NACK.  They are *not* superfluous.
> > > 
> > > XenServer uses them; xc_dom_linux_build() is the only way to apply
> > > XSA-25 size restrictions to PV kernels and initrds.
> > > 
> > Could you explain a bit more about this? How could this particular
> > function apply restrictions?
> > 
> > Unfortunately XSA-25 is not on XSA page so I have no idea what that is.
> > 
> > Wei.
> 
> Older XSAs are listed on the wiki
> http://wiki.xen.org/wiki/Security_Announcements
> 
> XSA-25 introduced xc_dom_{kernel,ramdisk}_max_size() to set upper
> decompression limits on the kernel and initrd.
> 
> To use them, a struct xc_dom_image *dom is needed, which means the only
> safe way of constructing PV domains is
> 
> xc_dom_allocate()
> xc_dom_kernel_max_size()
> xc_dom_ramdisk_max_size()
> xc_dom_linux_build()
> 
> To have the decompression limits in place before decompression starts.

No it isn't.

xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
functions, so it should be possible to do what you want with out using the
compat wrapper.

If there is some obscure reason this isn't the case then we should fix
that, not carry around the compat options for ever as a workaround (fixes
include but are not limited to promoting xc_dom_linux_build into a non
-compat helper).

Ian.

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-06 13:17       ` Ian Campbell
@ 2015-10-19 10:36         ` Juergen Gross
  2015-10-22 15:22           ` Ian Jackson
  2015-10-22 15:51           ` Andrew Cooper
  2015-10-22 15:21         ` Wei Liu
  1 sibling, 2 replies; 14+ messages in thread
From: Juergen Gross @ 2015-10-19 10:36 UTC (permalink / raw)
  To: Ian Campbell, Andrew Cooper, Wei Liu
  Cc: xen-devel, ian.jackson, stefano.stabellini

On 10/06/2015 03:17 PM, Ian Campbell wrote:
> On Tue, 2015-10-06 at 14:06 +0100, Andrew Cooper wrote:
>> On 06/10/15 13:58, Wei Liu wrote:
>>> On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
>>>> On 06/10/15 12:35, Juergen Gross wrote:
>>>>> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is
>>>>> currently
>>>>> being used by an in-tree component (qemu-xen). All other functions
>>>>> are
>>>>> superfluous wrappers of the domain builder which can be removed.
>>>>>
>>>>> Suggested-by: Ian Campbell <ian.campbell@citrix.com>
>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>> Sorry, but NACK.  They are *not* superfluous.
>>>>
>>>> XenServer uses them; xc_dom_linux_build() is the only way to apply
>>>> XSA-25 size restrictions to PV kernels and initrds.
>>>>
>>> Could you explain a bit more about this? How could this particular
>>> function apply restrictions?
>>>
>>> Unfortunately XSA-25 is not on XSA page so I have no idea what that is.
>>>
>>> Wei.
>>
>> Older XSAs are listed on the wiki
>> http://wiki.xen.org/wiki/Security_Announcements
>>
>> XSA-25 introduced xc_dom_{kernel,ramdisk}_max_size() to set upper
>> decompression limits on the kernel and initrd.
>>
>> To use them, a struct xc_dom_image *dom is needed, which means the only
>> safe way of constructing PV domains is
>>
>> xc_dom_allocate()
>> xc_dom_kernel_max_size()
>> xc_dom_ramdisk_max_size()
>> xc_dom_linux_build()
>>
>> To have the decompression limits in place before decompression starts.
>
> No it isn't.
>
> xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
> functions, so it should be possible to do what you want with out using the
> compat wrapper.
>
> If there is some obscure reason this isn't the case then we should fix
> that, not carry around the compat options for ever as a workaround (fixes
> include but are not limited to promoting xc_dom_linux_build into a non
> -compat helper).

Any further comments?

Andrew, are you okay with Ian's statement?

Ian, does this mean you are Ack-ing the patch?


Juergen

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-06 13:17       ` Ian Campbell
  2015-10-19 10:36         ` Juergen Gross
@ 2015-10-22 15:21         ` Wei Liu
  1 sibling, 0 replies; 14+ messages in thread
From: Wei Liu @ 2015-10-22 15:21 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Juergen Gross, Wei Liu, stefano.stabellini, Andrew Cooper,
	ian.jackson, xen-devel

On Tue, Oct 06, 2015 at 02:17:41PM +0100, Ian Campbell wrote:
> On Tue, 2015-10-06 at 14:06 +0100, Andrew Cooper wrote:
> > On 06/10/15 13:58, Wei Liu wrote:
> > > On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
> > > > On 06/10/15 12:35, Juergen Gross wrote:
> > > > > In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is
> > > > > currently
> > > > > being used by an in-tree component (qemu-xen). All other functions
> > > > > are
> > > > > superfluous wrappers of the domain builder which can be removed.
> > > > > 
> > > > > Suggested-by: Ian Campbell <ian.campbell@citrix.com>
> > > > > Signed-off-by: Juergen Gross <jgross@suse.com>
> > > > Sorry, but NACK.  They are *not* superfluous.
> > > > 
> > > > XenServer uses them; xc_dom_linux_build() is the only way to apply
> > > > XSA-25 size restrictions to PV kernels and initrds.
> > > > 
> > > Could you explain a bit more about this? How could this particular
> > > function apply restrictions?
> > > 
> > > Unfortunately XSA-25 is not on XSA page so I have no idea what that is.
> > > 
> > > Wei.
> > 
> > Older XSAs are listed on the wiki
> > http://wiki.xen.org/wiki/Security_Announcements
> > 
> > XSA-25 introduced xc_dom_{kernel,ramdisk}_max_size() to set upper
> > decompression limits on the kernel and initrd.
> > 
> > To use them, a struct xc_dom_image *dom is needed, which means the only
> > safe way of constructing PV domains is
> > 
> > xc_dom_allocate()
> > xc_dom_kernel_max_size()
> > xc_dom_ramdisk_max_size()
> > xc_dom_linux_build()
> > 
> > To have the decompression limits in place before decompression starts.
> 
> No it isn't.
> 
> xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
> functions, so it should be possible to do what you want with out using the
> compat wrapper.
> 
> If there is some obscure reason this isn't the case then we should fix
> that, not carry around the compat options for ever as a workaround (fixes
> include but are not limited to promoting xc_dom_linux_build into a non
> -compat helper).
> 

I agree with this reasoning so

Acked-by: Wei Liu <wei.liu2@citrix.com>

> Ian.

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-19 10:36         ` Juergen Gross
@ 2015-10-22 15:22           ` Ian Jackson
  2015-10-22 15:38             ` Ian Campbell
  2015-10-22 15:51           ` Andrew Cooper
  1 sibling, 1 reply; 14+ messages in thread
From: Ian Jackson @ 2015-10-22 15:22 UTC (permalink / raw)
  To: Juergen Gross
  Cc: Andrew Cooper, xen-devel, Wei Liu, Ian Campbell, stefano.stabellini

Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c"):
> On 10/06/2015 03:17 PM, Ian Campbell wrote:
> > xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
> > functions, so it should be possible to do what you want with out using the
> > compat wrapper.
> >
> > If there is some obscure reason this isn't the case then we should fix
> > that, not carry around the compat options for ever as a workaround (fixes
> > include but are not limited to promoting xc_dom_linux_build into a non
> > -compat helper).

I agree with this approach.

> Any further comments?
> 
> Andrew, are you okay with Ian's statement?
> 
> Ian, does this mean you are Ack-ing the patch?

Accordingly, in the absence of renewed objections, or alternative
proposals, the original patch is:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks,
Ian.

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-22 15:22           ` Ian Jackson
@ 2015-10-22 15:38             ` Ian Campbell
  2015-10-23  7:15               ` Juergen Gross
  0 siblings, 1 reply; 14+ messages in thread
From: Ian Campbell @ 2015-10-22 15:38 UTC (permalink / raw)
  To: Ian Jackson, Juergen Gross
  Cc: Andrew Cooper, xen-devel, Wei Liu, stefano.stabellini

On Thu, 2015-10-22 at 16:22 +0100, Ian Jackson wrote:
> Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxc: remove most of
> tools/libxc/xc_dom_compat_linux.c"):
> > On 10/06/2015 03:17 PM, Ian Campbell wrote:
> > > xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
> > > functions, so it should be possible to do what you want with out
> > > using the
> > > compat wrapper.
> > > 
> > > If there is some obscure reason this isn't the case then we should
> > > fix
> > > that, not carry around the compat options for ever as a workaround
> > > (fixes
> > > include but are not limited to promoting xc_dom_linux_build into a
> > > non
> > > -compat helper).
> 
> I agree with this approach.
> 
> > Any further comments?
> > 
> > Andrew, are you okay with Ian's statement?
> > 
> > Ian, does this mean you are Ack-ing the patch?
> 
> Accordingly, in the absence of renewed objections, or alternative
> proposals, the original patch is:
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

There was a conflict with "libxc: unify xc_dom_p2m_{host/guest}", where
xc_dom_p2m_host became xc_dom_p2m. I tried to resolve in what I thought was
the obvious way, but then I got many instances of:

    In file included from libxl.c:19:0:
    libxl_internal.h:1612:43: error: 'struct xc_dom_image' declared inside parameter list [-Werror]
                                        struct xc_dom_image *dom);
                                               ^
    libxl_internal.h:1612:43: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]

Not sure if the original patch was wrong, has bit-rotted, or I messed up
the conflict resolution. This happens on all arches.

Actually, looking back at it, the added "struct xc_dom_image" in
libxl_arch.h is surely wrong, the right answer would be to include xc_dom.h
somewhere appropriate it might be tolerable to just leave it in xenguest.h.

Juergen, please investigate the build failure, fix the above and resubmit.

Ian.

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-19 10:36         ` Juergen Gross
  2015-10-22 15:22           ` Ian Jackson
@ 2015-10-22 15:51           ` Andrew Cooper
  1 sibling, 0 replies; 14+ messages in thread
From: Andrew Cooper @ 2015-10-22 15:51 UTC (permalink / raw)
  To: Juergen Gross, Ian Campbell, Wei Liu
  Cc: xen-devel, ian.jackson, stefano.stabellini

On 19/10/15 11:36, Juergen Gross wrote:
> On 10/06/2015 03:17 PM, Ian Campbell wrote:
>> On Tue, 2015-10-06 at 14:06 +0100, Andrew Cooper wrote:
>>> On 06/10/15 13:58, Wei Liu wrote:
>>>> On Tue, Oct 06, 2015 at 01:52:16PM +0100, Andrew Cooper wrote:
>>>>> On 06/10/15 12:35, Juergen Gross wrote:
>>>>>> In tools/libxc/xc_dom_compat_linux.c only xc_linux_build() is
>>>>>> currently
>>>>>> being used by an in-tree component (qemu-xen). All other functions
>>>>>> are
>>>>>> superfluous wrappers of the domain builder which can be removed.
>>>>>>
>>>>>> Suggested-by: Ian Campbell <ian.campbell@citrix.com>
>>>>>> Signed-off-by: Juergen Gross <jgross@suse.com>
>>>>> Sorry, but NACK.  They are *not* superfluous.
>>>>>
>>>>> XenServer uses them; xc_dom_linux_build() is the only way to apply
>>>>> XSA-25 size restrictions to PV kernels and initrds.
>>>>>
>>>> Could you explain a bit more about this? How could this particular
>>>> function apply restrictions?
>>>>
>>>> Unfortunately XSA-25 is not on XSA page so I have no idea what that
>>>> is.
>>>>
>>>> Wei.
>>>
>>> Older XSAs are listed on the wiki
>>> http://wiki.xen.org/wiki/Security_Announcements
>>>
>>> XSA-25 introduced xc_dom_{kernel,ramdisk}_max_size() to set upper
>>> decompression limits on the kernel and initrd.
>>>
>>> To use them, a struct xc_dom_image *dom is needed, which means the only
>>> safe way of constructing PV domains is
>>>
>>> xc_dom_allocate()
>>> xc_dom_kernel_max_size()
>>> xc_dom_ramdisk_max_size()
>>> xc_dom_linux_build()
>>>
>>> To have the decompression limits in place before decompression starts.
>>
>> No it isn't.
>>
>> xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
>> functions, so it should be possible to do what you want with out
>> using the
>> compat wrapper.
>>
>> If there is some obscure reason this isn't the case then we should fix
>> that, not carry around the compat options for ever as a workaround
>> (fixes
>> include but are not limited to promoting xc_dom_linux_build into a non
>> -compat helper).
>
> Any further comments?
>
> Andrew, are you okay with Ian's statement?

Ah - I see that Xen 4.5 moves xc_dom.h from a private header file to a
public header file.

This postdates the last time I played "how to make xenctrl/xenguest
build a domain".

I shall see about modifying XenServer to use the gubbins from xc_dom.h

~Andrew

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-22 15:38             ` Ian Campbell
@ 2015-10-23  7:15               ` Juergen Gross
  2015-10-23  9:42                 ` Ian Campbell
  0 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2015-10-23  7:15 UTC (permalink / raw)
  To: Ian Campbell, Ian Jackson
  Cc: Andrew Cooper, xen-devel, Wei Liu, stefano.stabellini

On 10/22/2015 05:38 PM, Ian Campbell wrote:
> On Thu, 2015-10-22 at 16:22 +0100, Ian Jackson wrote:
>> Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxc: remove most of
>> tools/libxc/xc_dom_compat_linux.c"):
>>> On 10/06/2015 03:17 PM, Ian Campbell wrote:
>>>> xc_dom_linux_build is implemented in terms of the non-compat xc_dom_*
>>>> functions, so it should be possible to do what you want with out
>>>> using the
>>>> compat wrapper.
>>>>
>>>> If there is some obscure reason this isn't the case then we should
>>>> fix
>>>> that, not carry around the compat options for ever as a workaround
>>>> (fixes
>>>> include but are not limited to promoting xc_dom_linux_build into a
>>>> non
>>>> -compat helper).
>>
>> I agree with this approach.
>>
>>> Any further comments?
>>>
>>> Andrew, are you okay with Ian's statement?
>>>
>>> Ian, does this mean you are Ack-ing the patch?
>>
>> Accordingly, in the absence of renewed objections, or alternative
>> proposals, the original patch is:
>>
>> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
> There was a conflict with "libxc: unify xc_dom_p2m_{host/guest}", where
> xc_dom_p2m_host became xc_dom_p2m. I tried to resolve in what I thought was
> the obvious way, but then I got many instances of:
>
>      In file included from libxl.c:19:0:
>      libxl_internal.h:1612:43: error: 'struct xc_dom_image' declared inside parameter list [-Werror]
>                                          struct xc_dom_image *dom);
>                                                 ^
>      libxl_internal.h:1612:43: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
>
> Not sure if the original patch was wrong, has bit-rotted, or I messed up
> the conflict resolution. This happens on all arches.
>
> Actually, looking back at it, the added "struct xc_dom_image" in
> libxl_arch.h is surely wrong, the right answer would be to include xc_dom.h
> somewhere appropriate it might be tolerable to just leave it in xenguest.h.
>
> Juergen, please investigate the build failure, fix the above and resubmit.

That was easy. Just removing the definition for libxl_arch.h, include
xc_dom.h from libxl_internal.h and modify xc_dom.h to tolerate including
it multiple times.

I've stumbled over another issue:

I don't know what I did wrong, but obviously the patch was built on top
of the libxc python wrappers removal patch. Without that there are still
some functions in use which I wanted to remove in xc_dom_compat_linux.c

As there was no objection for the intention of removing most of the
wrappers I'll resend the xc_dom_compat_linux.c cleanup patch together
with the libxc python wrappers cleanup in a series.


Juergen

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-23  7:15               ` Juergen Gross
@ 2015-10-23  9:42                 ` Ian Campbell
  2015-10-23  9:53                   ` Juergen Gross
  0 siblings, 1 reply; 14+ messages in thread
From: Ian Campbell @ 2015-10-23  9:42 UTC (permalink / raw)
  To: Juergen Gross, Ian Jackson
  Cc: Andrew Cooper, xen-devel, Wei Liu, stefano.stabellini

On Fri, 2015-10-23 at 09:15 +0200, Juergen Gross wrote:
> On 10/22/2015 05:38 PM, Ian Campbell wrote:
> > On Thu, 2015-10-22 at 16:22 +0100, Ian Jackson wrote:
> > > Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxc: remove most of
> > > tools/libxc/xc_dom_compat_linux.c"):
> > > > On 10/06/2015 03:17 PM, Ian Campbell wrote:
> > > > > xc_dom_linux_build is implemented in terms of the non-compat
> > > > > xc_dom_*
> > > > > functions, so it should be possible to do what you want with out
> > > > > using the
> > > > > compat wrapper.
> > > > > 
> > > > > If there is some obscure reason this isn't the case then we
> > > > > should
> > > > > fix
> > > > > that, not carry around the compat options for ever as a
> > > > > workaround
> > > > > (fixes
> > > > > include but are not limited to promoting xc_dom_linux_build into
> > > > > a
> > > > > non
> > > > > -compat helper).
> > > 
> > > I agree with this approach.
> > > 
> > > > Any further comments?
> > > > 
> > > > Andrew, are you okay with Ian's statement?
> > > > 
> > > > Ian, does this mean you are Ack-ing the patch?
> > > 
> > > Accordingly, in the absence of renewed objections, or alternative
> > > proposals, the original patch is:
> > > 
> > > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > There was a conflict with "libxc: unify xc_dom_p2m_{host/guest}", where
> > xc_dom_p2m_host became xc_dom_p2m. I tried to resolve in what I thought
> > was
> > the obvious way, but then I got many instances of:
> > 
> >      In file included from libxl.c:19:0:
> >      libxl_internal.h:1612:43: error: 'struct xc_dom_image' declared
> > inside parameter list [-Werror]
> >                                          struct xc_dom_image *dom);
> >                                                 ^
> >      libxl_internal.h:1612:43: error: its scope is only this definition
> > or declaration, which is probably not what you want [-Werror]
> > 
> > Not sure if the original patch was wrong, has bit-rotted, or I messed
> > up
> > the conflict resolution. This happens on all arches.
> > 
> > Actually, looking back at it, the added "struct xc_dom_image" in
> > libxl_arch.h is surely wrong, the right answer would be to include
> > xc_dom.h
> > somewhere appropriate it might be tolerable to just leave it in
> > xenguest.h.
> > 
> > Juergen, please investigate the build failure, fix the above and
> > resubmit.
> 
> That was easy. Just removing the definition for libxl_arch.h, include
> xc_dom.h from libxl_internal.h and modify xc_dom.h to tolerate including
> it multiple times.
> 
> I've stumbled over another issue:
> 
> I don't know what I did wrong, but obviously the patch was built on top
> of the libxc python wrappers removal patch. Without that there are still
> some functions in use which I wanted to remove in xc_dom_compat_linux.c
> 
> As there was no objection for the intention of removing most of the
> wrappers I'll resend the xc_dom_compat_linux.c cleanup patch together
> with the libxc python wrappers cleanup in a series.

OK. Please put the xc_dom_compat_linux.c parts towards the head of the
series, such that they don't get blocked by any subsequent kvetching about
any specific Python removal. (Except you should remove the Python wrappers
for anything in xc_dom_compat_linux.c in the same patch as the removal of
the C version).

Ian.

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-23  9:42                 ` Ian Campbell
@ 2015-10-23  9:53                   ` Juergen Gross
  2015-10-23 10:11                     ` Ian Campbell
  0 siblings, 1 reply; 14+ messages in thread
From: Juergen Gross @ 2015-10-23  9:53 UTC (permalink / raw)
  To: Ian Campbell, Ian Jackson
  Cc: Andrew Cooper, xen-devel, Wei Liu, stefano.stabellini

On 10/23/2015 11:42 AM, Ian Campbell wrote:
> On Fri, 2015-10-23 at 09:15 +0200, Juergen Gross wrote:
>> On 10/22/2015 05:38 PM, Ian Campbell wrote:
>>> On Thu, 2015-10-22 at 16:22 +0100, Ian Jackson wrote:
>>>> Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxc: remove most of
>>>> tools/libxc/xc_dom_compat_linux.c"):
>>>>> On 10/06/2015 03:17 PM, Ian Campbell wrote:
>>>>>> xc_dom_linux_build is implemented in terms of the non-compat
>>>>>> xc_dom_*
>>>>>> functions, so it should be possible to do what you want with out
>>>>>> using the
>>>>>> compat wrapper.
>>>>>>
>>>>>> If there is some obscure reason this isn't the case then we
>>>>>> should
>>>>>> fix
>>>>>> that, not carry around the compat options for ever as a
>>>>>> workaround
>>>>>> (fixes
>>>>>> include but are not limited to promoting xc_dom_linux_build into
>>>>>> a
>>>>>> non
>>>>>> -compat helper).
>>>>
>>>> I agree with this approach.
>>>>
>>>>> Any further comments?
>>>>>
>>>>> Andrew, are you okay with Ian's statement?
>>>>>
>>>>> Ian, does this mean you are Ack-ing the patch?
>>>>
>>>> Accordingly, in the absence of renewed objections, or alternative
>>>> proposals, the original patch is:
>>>>
>>>> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
>>>
>>> There was a conflict with "libxc: unify xc_dom_p2m_{host/guest}", where
>>> xc_dom_p2m_host became xc_dom_p2m. I tried to resolve in what I thought
>>> was
>>> the obvious way, but then I got many instances of:
>>>
>>>       In file included from libxl.c:19:0:
>>>       libxl_internal.h:1612:43: error: 'struct xc_dom_image' declared
>>> inside parameter list [-Werror]
>>>                                           struct xc_dom_image *dom);
>>>                                                  ^
>>>       libxl_internal.h:1612:43: error: its scope is only this definition
>>> or declaration, which is probably not what you want [-Werror]
>>>
>>> Not sure if the original patch was wrong, has bit-rotted, or I messed
>>> up
>>> the conflict resolution. This happens on all arches.
>>>
>>> Actually, looking back at it, the added "struct xc_dom_image" in
>>> libxl_arch.h is surely wrong, the right answer would be to include
>>> xc_dom.h
>>> somewhere appropriate it might be tolerable to just leave it in
>>> xenguest.h.
>>>
>>> Juergen, please investigate the build failure, fix the above and
>>> resubmit.
>>
>> That was easy. Just removing the definition for libxl_arch.h, include
>> xc_dom.h from libxl_internal.h and modify xc_dom.h to tolerate including
>> it multiple times.
>>
>> I've stumbled over another issue:
>>
>> I don't know what I did wrong, but obviously the patch was built on top
>> of the libxc python wrappers removal patch. Without that there are still
>> some functions in use which I wanted to remove in xc_dom_compat_linux.c
>>
>> As there was no objection for the intention of removing most of the
>> wrappers I'll resend the xc_dom_compat_linux.c cleanup patch together
>> with the libxc python wrappers cleanup in a series.
>
> OK. Please put the xc_dom_compat_linux.c parts towards the head of the
> series, such that they don't get blocked by any subsequent kvetching about
> any specific Python removal. (Except you should remove the Python wrappers
> for anything in xc_dom_compat_linux.c in the same patch as the removal of
> the C version).

Just to get it right: You are suggesting I do two patches:

- Patch 1: cleanup of xc_dom_compat_linux.c + removal of all python
   wrappers affected by this cleanup (this would be xc.linux_build() and
   xc.getBitSize() ).

- Patch 2: removal of the rest of the python wrappers

Is this your preferred approach?


Juergen

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

* Re: [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c
  2015-10-23  9:53                   ` Juergen Gross
@ 2015-10-23 10:11                     ` Ian Campbell
  0 siblings, 0 replies; 14+ messages in thread
From: Ian Campbell @ 2015-10-23 10:11 UTC (permalink / raw)
  To: Juergen Gross, Ian Jackson
  Cc: Andrew Cooper, xen-devel, Wei Liu, stefano.stabellini

On Fri, 2015-10-23 at 11:53 +0200, Juergen Gross wrote:
> On 10/23/2015 11:42 AM, Ian Campbell wrote:
> > On Fri, 2015-10-23 at 09:15 +0200, Juergen Gross wrote:
> > > On 10/22/2015 05:38 PM, Ian Campbell wrote:
> > > > On Thu, 2015-10-22 at 16:22 +0100, Ian Jackson wrote:
> > > > > Juergen Gross writes ("Re: [Xen-devel] [PATCH] libxc: remove most
> > > > > of
> > > > > tools/libxc/xc_dom_compat_linux.c"):
> > > > > > On 10/06/2015 03:17 PM, Ian Campbell wrote:
> > > > > > > xc_dom_linux_build is implemented in terms of the non-compat
> > > > > > > xc_dom_*
> > > > > > > functions, so it should be possible to do what you want with
> > > > > > > out
> > > > > > > using the
> > > > > > > compat wrapper.
> > > > > > > 
> > > > > > > If there is some obscure reason this isn't the case then we
> > > > > > > should
> > > > > > > fix
> > > > > > > that, not carry around the compat options for ever as a
> > > > > > > workaround
> > > > > > > (fixes
> > > > > > > include but are not limited to promoting xc_dom_linux_build
> > > > > > > into
> > > > > > > a
> > > > > > > non
> > > > > > > -compat helper).
> > > > > 
> > > > > I agree with this approach.
> > > > > 
> > > > > > Any further comments?
> > > > > > 
> > > > > > Andrew, are you okay with Ian's statement?
> > > > > > 
> > > > > > Ian, does this mean you are Ack-ing the patch?
> > > > > 
> > > > > Accordingly, in the absence of renewed objections, or alternative
> > > > > proposals, the original patch is:
> > > > > 
> > > > > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > > > 
> > > > There was a conflict with "libxc: unify xc_dom_p2m_{host/guest}",
> > > > where
> > > > xc_dom_p2m_host became xc_dom_p2m. I tried to resolve in what I
> > > > thought
> > > > was
> > > > the obvious way, but then I got many instances of:
> > > > 
> > > >       In file included from libxl.c:19:0:
> > > >       libxl_internal.h:1612:43: error: 'struct xc_dom_image'
> > > > declared
> > > > inside parameter list [-Werror]
> > > >                                           struct xc_dom_image
> > > > *dom);
> > > >                                                  ^
> > > >       libxl_internal.h:1612:43: error: its scope is only this
> > > > definition
> > > > or declaration, which is probably not what you want [-Werror]
> > > > 
> > > > Not sure if the original patch was wrong, has bit-rotted, or I
> > > > messed
> > > > up
> > > > the conflict resolution. This happens on all arches.
> > > > 
> > > > Actually, looking back at it, the added "struct xc_dom_image" in
> > > > libxl_arch.h is surely wrong, the right answer would be to include
> > > > xc_dom.h
> > > > somewhere appropriate it might be tolerable to just leave it in
> > > > xenguest.h.
> > > > 
> > > > Juergen, please investigate the build failure, fix the above and
> > > > resubmit.
> > > 
> > > That was easy. Just removing the definition for libxl_arch.h, include
> > > xc_dom.h from libxl_internal.h and modify xc_dom.h to tolerate
> > > including
> > > it multiple times.
> > > 
> > > I've stumbled over another issue:
> > > 
> > > I don't know what I did wrong, but obviously the patch was built on
> > > top
> > > of the libxc python wrappers removal patch. Without that there are
> > > still
> > > some functions in use which I wanted to remove in
> > > xc_dom_compat_linux.c
> > > 
> > > As there was no objection for the intention of removing most of the
> > > wrappers I'll resend the xc_dom_compat_linux.c cleanup patch together
> > > with the libxc python wrappers cleanup in a series.
> > 
> > OK. Please put the xc_dom_compat_linux.c parts towards the head of the
> > series, such that they don't get blocked by any subsequent kvetching
> > about
> > any specific Python removal. (Except you should remove the Python
> > wrappers
> > for anything in xc_dom_compat_linux.c in the same patch as the removal
> > of
> > the C version).
> 
> Just to get it right: You are suggesting I do two patches:
> 
> - Patch 1: cleanup of xc_dom_compat_linux.c + removal of all python
>    wrappers affected by this cleanup (this would be xc.linux_build() and
>    xc.getBitSize() ).

Hrm, xc_get_bit_size seems like an odd thing to be in xc_dom_compat_linux.c(i.e. I wasn't expecting that sort of thing to be there).

I'd suggest doing most of xc_dom_compat_linux.c in a first patch (i.e. all
the semantically related "build a domain" type stuff) and then
xc_dom_bit_size separately.

> - Patch 2: removal of the rest of the python wrappers

I'm not sure exactly how much you are planning to remove in one fell swoop
here. If it is lots of seemingly unrelated stuff then my preference would
probably be to do it if possible in some vaguely related chunks by
functionality, such that an objection to one piece of functionality being
removed needn't block the entire patch.

Ian.

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

end of thread, other threads:[~2015-10-23 10:11 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-06 11:35 [PATCH] libxc: remove most of tools/libxc/xc_dom_compat_linux.c Juergen Gross
2015-10-06 12:52 ` Andrew Cooper
2015-10-06 12:58   ` Wei Liu
2015-10-06 13:06     ` Andrew Cooper
2015-10-06 13:17       ` Ian Campbell
2015-10-19 10:36         ` Juergen Gross
2015-10-22 15:22           ` Ian Jackson
2015-10-22 15:38             ` Ian Campbell
2015-10-23  7:15               ` Juergen Gross
2015-10-23  9:42                 ` Ian Campbell
2015-10-23  9:53                   ` Juergen Gross
2015-10-23 10:11                     ` Ian Campbell
2015-10-22 15:51           ` Andrew Cooper
2015-10-22 15:21         ` Wei Liu

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.