[PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Here's a slew of build fixes as well as build warning fixes
required when using the latest build tools, at least gcc 5 and
binutils 2.25.0. I ran into this while doing development on OpenSUSE
factory. Other rolling distros seem to be having similar issues based
on inspection of recent patches.

After fixing the issue I looked into the respective upstream
projects where are appropriate and provided annotations for
respective upstream fixes. The patches that have a respective upstream
project but do not have upstream annotations lack the annotations are
upstream code has already changed considerably and the patches do not
apply or the code has already been fixed but the respective upstream
atomic fix does not apply to our code branch. That said then, there is
no need to send anything to our usptream. My changes actually do have
a bit better annotations for some fixes than upstream, specifically
where I see a change fixed an issue I explain the actual issue that
should have been caused without the patch. That should make it easier
to evaluate integration of the patches into a stable branch or not.

Since some patches are part of upstream you could just consider
bumping upstream, or pulling the respective patch from upstream,
some of my annotations however have a bit better explanation for
why we wnat the changes. For stable branches these could be considere
as backport fixes. Up to you to decide how you want to manage these
fixes.

I've build tested this on both the xen master branch and the
xen stable-4.6 branch, so feel free to consider some of these into
stable-4.6 if its desirable to build Xen with the latest and greatest gcc
and binutils. I've only run time tested the master branch of Xen
on dom0 with these changes.

Changes are required on a slew of different trees. The order of the
patches match the order in which I found the issues and fixed them,
the summary of the changes for each different tree is below.

These following patches just fix warnings and as such are not required to
complete proper building, but they seem worthy enough at least for
consideration on unstable:

  hw/usb-net.c: fix state check
  qemu-xen-dir: virtio-rng: fix check for period_ms validity
  mini-os: fix linker warning with app.lds
  vtpm: fix vtpmblk.c compilation warning
  vtpm: guard against redefining TPM_VENDOR_COMMAND

The rest are definitely needed for proper building.

The gnutls fix goes with a Coccinelle rule file which should enable
proper transformation of the needed changes in other projects, so
long as the code matches in form. The Coccinelle rule file changes
can also enable the same patch to be easily rebased should the code
change in between the patch being considered for merging which would
otherwise cause a legacy patch conflict.

------------------------------------------------------------------------------
tools/firmware/seabios-dir-remote/

Luis R. Rodriguez (1):
  Revert "Use the extra stack for 16bit USB and PS2 keyboard/mouse commands."

 src/kbd.c   | 6 +++---                                                         
 src/mouse.c | 6 +++---                                                         
 2 files changed, 6 insertions(+), 6 deletions(-)  
------------------------------------------------------------------------------
tools/qemu-xen-traditional-dir-remote/

Luis R. Rodriguez (2):
  Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
  hw/usb-net.c: fix state check

 hw/usb-net.c |  4 ++--
 vnc.c        | 21 +--------------------
 2 files changed, 3 insertions(+), 22 deletions(-)
------------------------------------------------------------------------------
tools/qemu-xen-dir-remote/

Luis R. Rodriguez (2):
  qemu-xen-dir: avoid using spice-experimental.h
  qemu-xen-dir: virtio-rng: fix check for period_ms validity

 hw/virtio/virtio-rng.c | 2 +-
 spice-qemu-char.c      | 1 -
 ui/spice-core.c        | 1 -
 3 files changed, 1 insertion(+), 3 deletions(-)
------------------------------------------------------------------------------
extras/mini-os-remote/

Luis R. Rodriguez (1):
  mini-os: fix linker warning with app.lds

 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
------------------------------------------------------------------------------
Top level xen git tree on stubdom/

Luis R. Rodriguez (3):
  stubdom: fix unfound libgmp library issues
  vtpm: fix vtpmblk.c compilation warning
  vtpm: guard against redefining TPM_VENDOR_COMMAND

 stubdom/Makefile               | 5 +++++
 stubdom/vtpm/vtpmblk.c         | 1 +
 stubdom/vtpmmgr/vtpm_manager.h | 3 +++
 3 files changed, 9 insertions(+)

-- 
2.6.2

[PATCH 1/9] Revert "Use the extra stack for 16bit USB and PS2 keyboard/mouse commands."

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Upstream commit 12085439561f44107c7d3bea5a333a90ea987643

Kevin made this change upstream to seabios, this is needed for gcc5.
Mark Pryor reported the issue with gcc5 a while ago [0], he however
failed to follow up with an explanation as to what this does and why
this is needed.

	Revert "Use the extra stack for 16bit USB and PS2 keyboard/mouse commands."

	It's not valid to pass a pointer to a stack variable through the
	stack_hop() call (because the call changes the stack segment).  This
	bug was probably not noticed before because by default
	(CONFIG_ENTRY_EXTRASTACK) SeaBIOS uses the extra stack on all 16bit
	entry points, and the internal stack_hop() with that config option is
	effectively a no-op.

	This reverts commit d488a7683d90bf8fae7ceb8c3ad9e95fbbd92079.

	Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

[0] http://lkml.kernel.org/r/1444332991-1706-1-git-send-email-pryorm09@gmail.com

Reported-by: Mark Pryor <pryorm09@gmail.com>
Cc: Kevin O'Connor <kevin@koconnor.net>
Cc: ian.campbell@citrix.com
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Mark Pryor <pryorm09@gmail.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 src/kbd.c   | 6 +++---
 src/mouse.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/kbd.c b/src/kbd.c
index 33a95a398feb..fbcecc382eff 100644
--- a/src/kbd.c
+++ b/src/kbd.c
@@ -11,7 +11,7 @@
 #include "hw/ps2port.h" // ps2_kbd_command
 #include "hw/usb-hid.h" // usb_kbd_command
 #include "output.h" // debug_enter
-#include "stacks.h" // stack_hop
+#include "stacks.h" // yield
 #include "string.h" // memset
 #include "util.h" // kbd_init
 
@@ -117,8 +117,8 @@ static int
 kbd_command(int command, u8 *param)
 {
     if (usb_kbd_active())
-        return stack_hop(command, (u32)param, usb_kbd_command);
-    return stack_hop(command, (u32)param, ps2_kbd_command);
+        return usb_kbd_command(command, param);
+    return ps2_kbd_command(command, param);
 }
 
 // read keyboard input
diff --git a/src/mouse.c b/src/mouse.c
index 92ae9212c849..100255d60cfb 100644
--- a/src/mouse.c
+++ b/src/mouse.c
@@ -10,7 +10,7 @@
 #include "hw/ps2port.h" // ps2_mouse_command
 #include "hw/usb-hid.h" // usb_mouse_command
 #include "output.h" // dprintf
-#include "stacks.h" // stack_hop
+#include "stacks.h" // stack_hop_back
 #include "util.h" // mouse_init
 
 void
@@ -27,8 +27,8 @@ static int
 mouse_command(int command, u8 *param)
 {
     if (usb_mouse_active())
-        return stack_hop(command, (u32)param, usb_mouse_command);
-    return stack_hop(command, (u32)param, ps2_mouse_command);
+        return usb_mouse_command(command, param);
+    return ps2_mouse_command(command, param);
 }
 
 #define RET_SUCCESS      0x00
-- 
2.6.2

[Cocci] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Using deprecate gnutls_*_set() triggers a failure to compile
with gnutls30-3.4.4, used on OpenSUSE factory:

../libqemu_common.a(vnc.o): In function `vnc_start_tls':
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'

This compilation issue can be fixed by using the new routine
gnutls_priority_set_direct() which replaces the deprecated calls
which also simplifies the code considerably.

The following Coccinelle rule expresses the change in a general
grammar form, this could be used should the code be rebased, or
to do the transformation in other projects using the same gnutls
library.

@ vars @
identifier kx_x509, kx_anon, cert_type_priority, protocol_priority;
declarer name NEED_X509_AUTH;
@@

-int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
-int kx_anon[] = { GNUTLS_KX_ANON_DH, 0};
-int kx_x509[] = { GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};

@ calls_kx_set_priority @
identifier vars.kx_x509, vars.kx_anon;
expression need_x509;
struct VncState *vs;
@@

-if (gnutls_kx_set_priority(vs->tls_session, need_x509 ? kx_x509 : kx_anon) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}

@ calls_certificate_type_set_priority depends on calls_kx_set_priority @
identifier vars.cert_type_priority;
struct VncState *calls_kx_set_priority.vs;
@@
-if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}

@ calls_protocol_set_priority depends on calls_certificate_type_set_priority @
identifier vars.protocol_priority;
struct VncState *calls_kx_set_priority.vs;
expression calls_kx_set_priority.need_x509;
@@

-if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}
+if (gnutls_priority_set_direct(vs->tls_session, need_x509 ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
+	gnutls_deinit(vs->tls_session);
+	vs->tls_session = NULL;
+	vnc_client_error(vs);
+	return -1;
+}

Generated-by: Coccinelle SmPL
Cc: cocci at systeme.lip6.fr
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 vnc.c | 21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/vnc.c b/vnc.c
index 7629dfa18645..32c604084a5b 100644
--- a/vnc.c
+++ b/vnc.c
@@ -2137,11 +2137,6 @@ static void vnc_handshake_io(void *opaque) {
 
 
 static int vnc_start_tls(struct VncState *vs) {
-    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
-    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
-
     VNC_DEBUG("Do TLS setup\n");
     if (vnc_tls_initialize() < 0) {
 	VNC_DEBUG("Failed to init TLS\n");
@@ -2161,21 +2156,7 @@ static int vnc_start_tls(struct VncState *vs) {
 	    return -1;
 	}
 
-	if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? kx_x509 : kx_anon) < 0) {
-	    gnutls_deinit(vs->tls_session);
-	    vs->tls_session = NULL;
-	    vnc_client_error(vs);
-	    return -1;
-	}
-
-	if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
-	    gnutls_deinit(vs->tls_session);
-	    vs->tls_session = NULL;
-	    vnc_client_error(vs);
-	    return -1;
-	}
-
-	if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
+	if (gnutls_priority_set_direct(vs->tls_session, NEED_X509_AUTH(vs) ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
 	    gnutls_deinit(vs->tls_session);
 	    vs->tls_session = NULL;
 	    vnc_client_error(vs);
-- 
2.6.2

[PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Using deprecate gnutls_*_set() triggers a failure to compile
with gnutls30-3.4.4, used on OpenSUSE factory:

../libqemu_common.a(vnc.o): In function `vnc_start_tls':
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'

This compilation issue can be fixed by using the new routine
gnutls_priority_set_direct() which replaces the deprecated calls
which also simplifies the code considerably.

The following Coccinelle rule expresses the change in a general
grammar form, this could be used should the code be rebased, or
to do the transformation in other projects using the same gnutls
library.

@ vars @
identifier kx_x509, kx_anon, cert_type_priority, protocol_priority;
declarer name NEED_X509_AUTH;
@@

-int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
-int kx_anon[] = { GNUTLS_KX_ANON_DH, 0};
-int kx_x509[] = { GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};

@ calls_kx_set_priority @
identifier vars.kx_x509, vars.kx_anon;
expression need_x509;
struct VncState *vs;
@@

-if (gnutls_kx_set_priority(vs->tls_session, need_x509 ? kx_x509 : kx_anon) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}

@ calls_certificate_type_set_priority depends on calls_kx_set_priority @
identifier vars.cert_type_priority;
struct VncState *calls_kx_set_priority.vs;
@@
-if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}

@ calls_protocol_set_priority depends on calls_certificate_type_set_priority @
identifier vars.protocol_priority;
struct VncState *calls_kx_set_priority.vs;
expression calls_kx_set_priority.need_x509;
@@

-if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}
+if (gnutls_priority_set_direct(vs->tls_session, need_x509 ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
+	gnutls_deinit(vs->tls_session);
+	vs->tls_session = NULL;
+	vnc_client_error(vs);
+	return -1;
+}

Generated-by: Coccinelle SmPL
Cc: cocci@systeme.lip6.fr
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 vnc.c | 21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/vnc.c b/vnc.c
index 7629dfa18645..32c604084a5b 100644
--- a/vnc.c
+++ b/vnc.c
@@ -2137,11 +2137,6 @@ static void vnc_handshake_io(void *opaque) {
 
 
 static int vnc_start_tls(struct VncState *vs) {
-    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
-    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
-
     VNC_DEBUG("Do TLS setup\n");
     if (vnc_tls_initialize() < 0) {
 	VNC_DEBUG("Failed to init TLS\n");
@@ -2161,21 +2156,7 @@ static int vnc_start_tls(struct VncState *vs) {
 	    return -1;
 	}
 
-	if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? kx_x509 : kx_anon) < 0) {
-	    gnutls_deinit(vs->tls_session);
-	    vs->tls_session = NULL;
-	    vnc_client_error(vs);
-	    return -1;
-	}
-
-	if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
-	    gnutls_deinit(vs->tls_session);
-	    vs->tls_session = NULL;
-	    vnc_client_error(vs);
-	    return -1;
-	}
-
-	if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
+	if (gnutls_priority_set_direct(vs->tls_session, NEED_X509_AUTH(vs) ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
 	    gnutls_deinit(vs->tls_session);
 	    vs->tls_session = NULL;
 	    vnc_client_error(vs);
-- 
2.6.2

[PATCH 3/9] hw/usb-net.c: fix state check

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

The existing check is incorrect, currently it will actually allow
the code path to move on regardless of the state, fix this.

This is fixed upstream on qemu by the following commit:

commit 98d23704138e0be17a3ed9eb2631077bf92cc028
Author: Peter Maydell <peter.maydell@linaro.org>
Date:   Wed Nov 9 21:09:23 2011 +0000

    hw/usb-net.c: Fix precedence bug when checking rndis_state

    "!X == 2" is always false (spotted by Coverity), so the checks
    for whether rndis is in the correct state would never fire.

    Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 hw/usb-net.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/usb-net.c b/hw/usb-net.c
index 863c25fd9cb9..b4b0f9409c2f 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -1376,7 +1376,7 @@ static void usbnet_receive(void *opaque, const uint8_t *buf, int size)
 
     if (s->rndis) {
         msg = (struct rndis_packet_msg_type *) s->in_buf;
-        if (!s->rndis_state == RNDIS_DATA_INITIALIZED)
+        if (s->rndis_state != RNDIS_DATA_INITIALIZED)
             return;
         if (size + sizeof(struct rndis_packet_msg_type) > sizeof(s->in_buf))
             return;
@@ -1409,7 +1409,7 @@ static int usbnet_can_receive(void *opaque)
 {
     USBNetState *s = opaque;
 
-    if (s->rndis && !s->rndis_state == RNDIS_DATA_INITIALIZED)
+    if (s->rndis && s->rndis_state != RNDIS_DATA_INITIALIZED)
         return 1;
 
     return !s->in_len;
-- 
2.6.2

[PATCH 4/9] qemu-xen-dir: spice: remove spice-experimental.h include

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Upstream qemu commit e0883e2de0ef36f254acc274e80ddeac13a2a8f6
("spice: remove spice-experimental.h include")

commit e0883e2de0ef36f254acc274e80ddeac13a2a8f6
Author: Marc-André Lureau <marcandre.lureau@gmail.com>
Date:   Mon Nov 17 16:52:49 2014 +0100

    spice: remove spice-experimental.h include
    
    Nothing seems to be using functions from spice-experimental.h (better
    that way). Let's remove its inclusion.
    
    Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

As per upstream spice-server development via commit
2e88eb705bd584720d09 ("server: Readd spice-experimental.h") [0]
the spice-experimental.h header has been included on qemu since
qemu upstream commit v2.3.0-rc0~135^2~1 without using any of
its symbols, the upstream spice project has kept it to avoid
compilation issues. One can compile qemu then with --disable-werror,
but just clean this up instead.

[0] http://cgit.freedesktop.org/spice/spice/commit/?id=2e88eb705bd584720d0940b4a5db5d99d1e9b38e

Cc: Christophe Fergeau <cfergeau@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@gmail.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 spice-qemu-char.c | 1 -
 ui/spice-core.c   | 1 -
 2 files changed, 2 deletions(-)

diff --git a/spice-qemu-char.c b/spice-qemu-char.c
index 8106e063c031..7e0d300777be 100644
--- a/spice-qemu-char.c
+++ b/spice-qemu-char.c
@@ -3,7 +3,6 @@
 #include "ui/qemu-spice.h"
 #include "sysemu/char.h"
 #include <spice.h>
-#include <spice-experimental.h>
 #include <spice/protocol.h>
 
 #include "qemu/osdep.h"
diff --git a/ui/spice-core.c b/ui/spice-core.c
index 6467fa477674..2eae2bd35fa2 100644
--- a/ui/spice-core.c
+++ b/ui/spice-core.c
@@ -16,7 +16,6 @@
  */
 
 #include <spice.h>
-#include <spice-experimental.h>
 
 #include <netdb.h>
 #include "sysemu/sysemu.h"
-- 
2.6.2


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

[PATCH 5/9] qemu-xen-dir: virtio-rng: fix check for period_ms validity

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Upstream fix a3a292c420d2 ("virtio-rng: fix check for period_ms validity")

On this upstream commit Amit fixed the compilation warning:

hw/virtio/virtio-rng.c: In function ‘virtio_rng_device_realize’:
hw/virtio/virtio-rng.c:152:31: error: logical not is only applied to the
left hand side of comparison [-Werror=logical-not-parentheses]
     if (!vrng->conf.period_ms > 0) {

This ports that fix over. Note that the impact of not having this is
that the rng->conf.period_ms was set to 0 this can go undetected. Note
that period_ms is a uint32_t so it cannot be negative anyway.

Cc: Amit Shah <amit.shah@redhat.com>
Cc: Gonglei <arei.gonglei@huawei.com>
Amos Kong <akong@redhat.com>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 hw/virtio/virtio-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-rng.c b/hw/virtio/virtio-rng.c
index 473c04410e9e..06e71782b2d1 100644
--- a/hw/virtio/virtio-rng.c
+++ b/hw/virtio/virtio-rng.c
@@ -149,7 +149,7 @@ static void virtio_rng_device_realize(DeviceState *dev, Error **errp)
     VirtIORNG *vrng = VIRTIO_RNG(dev);
     Error *local_err = NULL;
 
-    if (!vrng->conf.period_ms > 0) {
+    if (vrng->conf.period_ms <= 0) {
         error_setg(errp, "'period' parameter expects a positive integer");
         return;
     }
-- 
2.6.2


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

[PATCH 6/9] mini-os: fix linker warning with app.lds

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

We toss around the linker script app.lds without specifying -T,
this works but causes the following warning. Let's split this
the required objects and use -T for the linker script.

This fixes this linker warning:

mcgrof@ergon ~/devel/xen/stubdom (git::stable-4.6)$ make all 2>&1| grep warning| grep app
ld: warning: app.lds contains output sections; did you forget -T?

Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 2cb5e51a16d7..33d3c5870a6e 100644
--- a/Makefile
+++ b/Makefile
@@ -178,7 +178,7 @@ OBJS := $(filter-out $(OBJ_DIR)/daytime.o, $(OBJS))
 endif
 
 $(OBJ_DIR)/$(TARGET)_app.o: $(APP_OBJS) app.lds
-	$(LD) -r -d $(LDFLAGS) -\( $^ -\) $(APP_LDLIBS) --undefined main -o $@
+	$(LD) -r -d $(LDFLAGS) -\( $(APP_OBJS) -T app.lds -\) $(APP_LDLIBS) --undefined main -o $@
 
 ifneq ($(APP_OBJS),)
 APP_O=$(OBJ_DIR)/$(TARGET)_app.o 
-- 
2.6.2

[PATCH 7/9] stubdom: fix unfound libgmp library issues

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

With binutils 2.25.0 libgmp is not found. When building
studom's we build our own libgmp for each minios. On
x86-64 all libraries are put on the directory:

stubdom/cross-root-x86_64/x86_64-xen-elf/lib/

The exception is libgmp, it gets tosse don lib64. It doesn't
seem the latest linker might amend lib64 as a default search
path when using -nostdlib -- I cannot confirm from binutils
code changes that's the case yet, but at least through the
observed behaviour that seems to be the case.

Be explicit and peg the lib64 directory as part of the search
path as well when on x86-64. This fixes the following final
linker error:

ld -r -d -nostdlib
-L/sda3/home/mcgrof/devel/xen/stubdom/cross-root-x86_64/x86_64-xen-elf/lib
-m elf_x86_64 -\( /sda3/home/mcgrof/devel/xen/stubdom/vtpm/vtpm.a -T
app.lds -\) -ltpm -ltpm_crypto -lgmp -lpolarssl --undefined main -o
/sda3/home/mcgrof/devel/xen/stubdom/mini-os-x86_64-vtpm/mini-os_app.o
ld: cannot find -lgmp

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 stubdom/Makefile | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/stubdom/Makefile b/stubdom/Makefile
index e1359cfaf7e5..e01be070bf26 100644
--- a/stubdom/Makefile
+++ b/stubdom/Makefile
@@ -53,6 +53,11 @@ TARGET_CPPFLAGS += -I$(CURDIR)/include
 TARGET_CPPFLAGS += -I$(XEN_ROOT)/xen/include
 
 TARGET_LDFLAGS += -nostdlib -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib
+# lib64 is not pegged as default search path for archs for some versions
+# of binutils, its where libgmp gets tossed, so be explicit
+ifeq ($(XEN_TARGET_ARCH),x86_64)
+TARGET_LDFLAGS += -L$(CROSS_PREFIX)/$(GNU_TARGET_ARCH)-xen-elf/lib64
+endif
 
 TARGETS=$(STUBDOM_TARGETS)
 
-- 
2.6.2

[PATCH 8/9] vtpm: fix vtpmblk.c compilation warning

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Using gcc5 we get the following warning:

vtpmblk.c:322:7: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
vtpmblk.c:322:7: warning: incompatible implicit declaration of built-in function ‘printf’

Fix this by including stdio.h

Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 stubdom/vtpm/vtpmblk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/stubdom/vtpm/vtpmblk.c b/stubdom/vtpm/vtpmblk.c
index fe529ab5acbc..de8fbfa7f949 100644
--- a/stubdom/vtpm/vtpmblk.c
+++ b/stubdom/vtpm/vtpmblk.c
@@ -18,6 +18,7 @@
 #include "polarssl/sha1.h"
 #include <blkfront.h>
 #include <unistd.h>
+#include <stdio.h>
 #include <errno.h>
 #include <fcntl.h>
 
-- 
2.6.2


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

[PATCH 9/9] vtpm: guard against redefining TPM_VENDOR_COMMAND

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

vtpm.c already includes tpm/tpm_marshalling.h, this in turn
includes tpm_structures.h which already has defined
TPM_VENDOR_COMMAND. Guard against its redefinition to avoid
a compilation warning on vtpmc:

cc <etc> -I../tpm_emulator-x86_64  -c -o vtpm.o vtpm.c
In file included from vtpm.c:36:0: vtpm_manager.h:57:0: warning: "TPM_VENDOR_COMMAND" redefined
 #define TPM_VENDOR_COMMAND  0x02000000 // TPM Main, part 2, section 17.
 ^
In file included from ../tpm_emulator-x86_64/tpm/tpm_marshalling.h:21:0,
                 from vtpm.c:31:
../tpm_emulator-x86_64/tpm/tpm_structures.h:526:0: note: this is the
location of the previous definition

Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 stubdom/vtpmmgr/vtpm_manager.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/stubdom/vtpmmgr/vtpm_manager.h b/stubdom/vtpmmgr/vtpm_manager.h
index 2d2109dd63cb..6fdaf6aeb074 100644
--- a/stubdom/vtpmmgr/vtpm_manager.h
+++ b/stubdom/vtpmmgr/vtpm_manager.h
@@ -54,7 +54,10 @@
 
 //************************ Command Codes ****************************
 #define VTPM_ORD_BASE       0x0000
+/* Defined in tpm_emulator-x86_64/tpm/tpm_structures.h */
+#ifndef TPM_VENDOR_COMMAND
 #define TPM_VENDOR_COMMAND  0x02000000 // TPM Main, part 2, section 17.
+#endif
 #define VTPM_PRIV_BASE      (VTPM_ORD_BASE | TPM_VENDOR_COMMAND)
 
 /*
-- 
2.6.2

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Using deprecate gnutls_*_set() triggers a failure to compile
> with gnutls30-3.4.4, used on OpenSUSE factory:
> 
> ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> 
> This compilation issue can be fixed by using the new routine
> gnutls_priority_set_direct() which replaces the deprecated calls
> which also simplifies the code considerably.


Thanks for posting that! It certainly fixes that issue.

I was wondering if you had seen these as well:

/home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
?gnutls_anon_server_credentials? is deprecated
[-Wdeprecated-declarations]
 {
 ^
/home/konrad/qemu-trad.git/vnc.c: In function
?vnc_tls_initialize_anon_cred?:
/home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
?gnutls_anon_server_credentials? is deprecated
[-Wdeprecated-declarations]
     gnutls_anon_server_credentials anon_cred;
     ^
/home/konrad/qemu-trad.git/vnc.c: In function ?vnc_start_tls?:
/home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
?gnutls_anon_server_credentials? is deprecated
[-Wdeprecated-declarations]
      gnutls_anon_server_credentials anon_cred =
vnc_tls_initialize_anon_cred();
      ^
?

(This is Fedora 23)
> 
> The following Coccinelle rule expresses the change in a general
> grammar form, this could be used should the code be rebased, or
> to do the transformation in other projects using the same gnutls
> library.
> 
> @ vars @
> identifier kx_x509, kx_anon, cert_type_priority, protocol_priority;
> declarer name NEED_X509_AUTH;
> @@
> 
> -int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
> -int kx_anon[] = { GNUTLS_KX_ANON_DH, 0};
> -int kx_x509[] = { GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
> 
> @ calls_kx_set_priority @
> identifier vars.kx_x509, vars.kx_anon;
> expression need_x509;
> struct VncState *vs;
> @@
> 
> -if (gnutls_kx_set_priority(vs->tls_session, need_x509 ? kx_x509 : kx_anon) < 0) {
> -	gnutls_deinit(vs->tls_session);
> -	vs->tls_session = NULL;
> -	vnc_client_error(vs);
> -	return -1;
> -}
> 
> @ calls_certificate_type_set_priority depends on calls_kx_set_priority @
> identifier vars.cert_type_priority;
> struct VncState *calls_kx_set_priority.vs;
> @@
> -if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
> -	gnutls_deinit(vs->tls_session);
> -	vs->tls_session = NULL;
> -	vnc_client_error(vs);
> -	return -1;
> -}
> 
> @ calls_protocol_set_priority depends on calls_certificate_type_set_priority @
> identifier vars.protocol_priority;
> struct VncState *calls_kx_set_priority.vs;
> expression calls_kx_set_priority.need_x509;
> @@
> 
> -if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
> -	gnutls_deinit(vs->tls_session);
> -	vs->tls_session = NULL;
> -	vnc_client_error(vs);
> -	return -1;
> -}
> +if (gnutls_priority_set_direct(vs->tls_session, need_x509 ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
> +	gnutls_deinit(vs->tls_session);
> +	vs->tls_session = NULL;
> +	vnc_client_error(vs);
> +	return -1;
> +}
> 
> Generated-by: Coccinelle SmPL
> Cc: cocci at systeme.lip6.fr
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  vnc.c | 21 +--------------------
>  1 file changed, 1 insertion(+), 20 deletions(-)
> 
> diff --git a/vnc.c b/vnc.c
> index 7629dfa18645..32c604084a5b 100644
> --- a/vnc.c
> +++ b/vnc.c
> @@ -2137,11 +2137,6 @@ static void vnc_handshake_io(void *opaque) {
>  
>  
>  static int vnc_start_tls(struct VncState *vs) {
> -    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
> -    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
> -    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
> -
>      VNC_DEBUG("Do TLS setup\n");
>      if (vnc_tls_initialize() < 0) {
>  	VNC_DEBUG("Failed to init TLS\n");
> @@ -2161,21 +2156,7 @@ static int vnc_start_tls(struct VncState *vs) {
>  	    return -1;
>  	}
>  
> -	if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? kx_x509 : kx_anon) < 0) {
> -	    gnutls_deinit(vs->tls_session);
> -	    vs->tls_session = NULL;
> -	    vnc_client_error(vs);
> -	    return -1;
> -	}
> -
> -	if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
> -	    gnutls_deinit(vs->tls_session);
> -	    vs->tls_session = NULL;
> -	    vnc_client_error(vs);
> -	    return -1;
> -	}
> -
> -	if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
> +	if (gnutls_priority_set_direct(vs->tls_session, NEED_X509_AUTH(vs) ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
>  	    gnutls_deinit(vs->tls_session);
>  	    vs->tls_session = NULL;
>  	    vnc_client_error(vs);
> -- 
> 2.6.2
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> http://lists.xen.org/xen-devel

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Using deprecate gnutls_*_set() triggers a failure to compile
> with gnutls30-3.4.4, used on OpenSUSE factory:
> 
> ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> 
> This compilation issue can be fixed by using the new routine
> gnutls_priority_set_direct() which replaces the deprecated calls
> which also simplifies the code considerably.


Thanks for posting that! It certainly fixes that issue.

I was wondering if you had seen these as well:

/home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
‘gnutls_anon_server_credentials’ is deprecated
[-Wdeprecated-declarations]
 {
 ^
/home/konrad/qemu-trad.git/vnc.c: In function
‘vnc_tls_initialize_anon_cred’:
/home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
‘gnutls_anon_server_credentials’ is deprecated
[-Wdeprecated-declarations]
     gnutls_anon_server_credentials anon_cred;
     ^
/home/konrad/qemu-trad.git/vnc.c: In function ‘vnc_start_tls’:
/home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
‘gnutls_anon_server_credentials’ is deprecated
[-Wdeprecated-declarations]
      gnutls_anon_server_credentials anon_cred =
vnc_tls_initialize_anon_cred();
      ^
?

(This is Fedora 23)
> 
> The following Coccinelle rule expresses the change in a general
> grammar form, this could be used should the code be rebased, or
> to do the transformation in other projects using the same gnutls
> library.
> 
> @ vars @
> identifier kx_x509, kx_anon, cert_type_priority, protocol_priority;
> declarer name NEED_X509_AUTH;
> @@
> 
> -int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
> -int kx_anon[] = { GNUTLS_KX_ANON_DH, 0};
> -int kx_x509[] = { GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
> 
> @ calls_kx_set_priority @
> identifier vars.kx_x509, vars.kx_anon;
> expression need_x509;
> struct VncState *vs;
> @@
> 
> -if (gnutls_kx_set_priority(vs->tls_session, need_x509 ? kx_x509 : kx_anon) < 0) {
> -	gnutls_deinit(vs->tls_session);
> -	vs->tls_session = NULL;
> -	vnc_client_error(vs);
> -	return -1;
> -}
> 
> @ calls_certificate_type_set_priority depends on calls_kx_set_priority @
> identifier vars.cert_type_priority;
> struct VncState *calls_kx_set_priority.vs;
> @@
> -if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
> -	gnutls_deinit(vs->tls_session);
> -	vs->tls_session = NULL;
> -	vnc_client_error(vs);
> -	return -1;
> -}
> 
> @ calls_protocol_set_priority depends on calls_certificate_type_set_priority @
> identifier vars.protocol_priority;
> struct VncState *calls_kx_set_priority.vs;
> expression calls_kx_set_priority.need_x509;
> @@
> 
> -if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
> -	gnutls_deinit(vs->tls_session);
> -	vs->tls_session = NULL;
> -	vnc_client_error(vs);
> -	return -1;
> -}
> +if (gnutls_priority_set_direct(vs->tls_session, need_x509 ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
> +	gnutls_deinit(vs->tls_session);
> +	vs->tls_session = NULL;
> +	vnc_client_error(vs);
> +	return -1;
> +}
> 
> Generated-by: Coccinelle SmPL
> Cc: cocci@systeme.lip6.fr
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  vnc.c | 21 +--------------------
>  1 file changed, 1 insertion(+), 20 deletions(-)
> 
> diff --git a/vnc.c b/vnc.c
> index 7629dfa18645..32c604084a5b 100644
> --- a/vnc.c
> +++ b/vnc.c
> @@ -2137,11 +2137,6 @@ static void vnc_handshake_io(void *opaque) {
>  
>  
>  static int vnc_start_tls(struct VncState *vs) {
> -    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
> -    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
> -    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
> -    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
> -
>      VNC_DEBUG("Do TLS setup\n");
>      if (vnc_tls_initialize() < 0) {
>  	VNC_DEBUG("Failed to init TLS\n");
> @@ -2161,21 +2156,7 @@ static int vnc_start_tls(struct VncState *vs) {
>  	    return -1;
>  	}
>  
> -	if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? kx_x509 : kx_anon) < 0) {
> -	    gnutls_deinit(vs->tls_session);
> -	    vs->tls_session = NULL;
> -	    vnc_client_error(vs);
> -	    return -1;
> -	}
> -
> -	if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
> -	    gnutls_deinit(vs->tls_session);
> -	    vs->tls_session = NULL;
> -	    vnc_client_error(vs);
> -	    return -1;
> -	}
> -
> -	if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
> +	if (gnutls_priority_set_direct(vs->tls_session, NEED_X509_AUTH(vs) ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
>  	    gnutls_deinit(vs->tls_session);
>  	    vs->tls_session = NULL;
>  	    vnc_client_error(vs);
> -- 
> 2.6.2
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Using deprecate gnutls_*_set() triggers a failure to compile
> > with gnutls30-3.4.4, used on OpenSUSE factory:
> > 
> > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > 
> > This compilation issue can be fixed by using the new routine
> > gnutls_priority_set_direct() which replaces the deprecated calls
> > which also simplifies the code considerably.
> 
> 
> Thanks for posting that! It certainly fixes that issue.

Acked-by?

> I was wondering if you had seen these as well:
> 
> /home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
> ?gnutls_anon_server_credentials? is deprecated
> [-Wdeprecated-declarations]
>  {
>  ^
> /home/konrad/qemu-trad.git/vnc.c: In function
> ?vnc_tls_initialize_anon_cred?:
> /home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
> ?gnutls_anon_server_credentials? is deprecated
> [-Wdeprecated-declarations]
>      gnutls_anon_server_credentials anon_cred;
>      ^
> /home/konrad/qemu-trad.git/vnc.c: In function ?vnc_start_tls?:
> /home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
> ?gnutls_anon_server_credentials? is deprecated
> [-Wdeprecated-declarations]
>       gnutls_anon_server_credentials anon_cred =
> vnc_tls_initialize_anon_cred();
>       ^
> ?
> 
> (This is Fedora 23)

Nope.

 Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > Using deprecate gnutls_*_set() triggers a failure to compile
> > with gnutls30-3.4.4, used on OpenSUSE factory:
> > 
> > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > 
> > This compilation issue can be fixed by using the new routine
> > gnutls_priority_set_direct() which replaces the deprecated calls
> > which also simplifies the code considerably.
> 
> 
> Thanks for posting that! It certainly fixes that issue.

Acked-by?

> I was wondering if you had seen these as well:
> 
> /home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
> ‘gnutls_anon_server_credentials’ is deprecated
> [-Wdeprecated-declarations]
>  {
>  ^
> /home/konrad/qemu-trad.git/vnc.c: In function
> ‘vnc_tls_initialize_anon_cred’:
> /home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
> ‘gnutls_anon_server_credentials’ is deprecated
> [-Wdeprecated-declarations]
>      gnutls_anon_server_credentials anon_cred;
>      ^
> /home/konrad/qemu-trad.git/vnc.c: In function ‘vnc_start_tls’:
> /home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
> ‘gnutls_anon_server_credentials’ is deprecated
> [-Wdeprecated-declarations]
>       gnutls_anon_server_credentials anon_cred =
> vnc_tls_initialize_anon_cred();
>       ^
> ?
> 
> (This is Fedora 23)

Nope.

 Luis
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > 
> > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > 
> > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > 
> > > This compilation issue can be fixed by using the new routine
> > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > which also simplifies the code considerably.
> > 
> > 
> > Thanks for posting that! It certainly fixes that issue.
> 
> Acked-by?

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > I was wondering if you had seen these as well:
> > 
> > /home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
> > ?gnutls_anon_server_credentials? is deprecated
> > [-Wdeprecated-declarations]
> >  {
> >  ^
> > /home/konrad/qemu-trad.git/vnc.c: In function
> > ?vnc_tls_initialize_anon_cred?:
> > /home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
> > ?gnutls_anon_server_credentials? is deprecated
> > [-Wdeprecated-declarations]
> >      gnutls_anon_server_credentials anon_cred;
> >      ^
> > /home/konrad/qemu-trad.git/vnc.c: In function ?vnc_start_tls?:
> > /home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
> > ?gnutls_anon_server_credentials? is deprecated
> > [-Wdeprecated-declarations]
> >       gnutls_anon_server_credentials anon_cred =
> > vnc_tls_initialize_anon_cred();
> >       ^
> > ?
> > 
> > (This is Fedora 23)
> 
> Nope.
> 
>  Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > 
> > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > 
> > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > 
> > > This compilation issue can be fixed by using the new routine
> > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > which also simplifies the code considerably.
> > 
> > 
> > Thanks for posting that! It certainly fixes that issue.
> 
> Acked-by?

Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> > I was wondering if you had seen these as well:
> > 
> > /home/konrad/qemu-trad.git/vnc.c:1929:1: warning:
> > ‘gnutls_anon_server_credentials’ is deprecated
> > [-Wdeprecated-declarations]
> >  {
> >  ^
> > /home/konrad/qemu-trad.git/vnc.c: In function
> > ‘vnc_tls_initialize_anon_cred’:
> > /home/konrad/qemu-trad.git/vnc.c:1930:5: warning:
> > ‘gnutls_anon_server_credentials’ is deprecated
> > [-Wdeprecated-declarations]
> >      gnutls_anon_server_credentials anon_cred;
> >      ^
> > /home/konrad/qemu-trad.git/vnc.c: In function ‘vnc_start_tls’:
> > /home/konrad/qemu-trad.git/vnc.c:2203:6: warning:
> > ‘gnutls_anon_server_credentials’ is deprecated
> > [-Wdeprecated-declarations]
> >       gnutls_anon_server_credentials anon_cred =
> > vnc_tls_initialize_anon_cred();
> >       ^
> > ?
> > 
> > (This is Fedora 23)
> 
> Nope.
> 
>  Luis

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

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > 
> > > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > > 
> > > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > > 
> > > > This compilation issue can be fixed by using the new routine
> > > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > > which also simplifies the code considerably.
> > > 
> > > 
> > > Thanks for posting that! It certainly fixes that issue.
> > 
> > Acked-by?
> 
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

None of these are merged yet...

 Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > 
> > > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > > 
> > > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > > 
> > > > This compilation issue can be fixed by using the new routine
> > > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > > which also simplifies the code considerably.
> > > 
> > > 
> > > Thanks for posting that! It certainly fixes that issue.
> > 
> > Acked-by?
> 
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

None of these are merged yet...

 Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> Here's a slew of build fixes as well as build warning fixes
> required when using the latest build tools, at least gcc 5 and
> binutils 2.25.0.

One good reason for some folks to get discouraged to work with Xen:

Patches for fixes on builds last ages to get merged

In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
it was probably not the right fix. Last year in November I provided
what I think is a proper replacement set which I think addressed Jan's
concerns.

***Four*** months later and Xen still does not compile with the latest
and greatest. I have to go digging out in my git basement somewhere
some fixes I last used to build Xen to try to test some new
features...

What's up folks? How can this process be made smoother, did I do
something wrong, what can I do to help better? What can you do to help
ensure these types of things don't fall through the cracks.

[0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/264183

  Luis

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> > > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > 
> > > > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > > > 
> > > > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > > > 
> > > > > This compilation issue can be fixed by using the new routine
> > > > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > > > which also simplifies the code considerably.
> > > > 
> > > > 
> > > > Thanks for posting that! It certainly fixes that issue.
> > > 
> > > Acked-by?
> > 
> > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> None of these are merged yet...

And it looks like you didn't CC the maintainer.

Also - how does this work if you have an older version of SuSE,
say SLES10?
> 
>  Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote:
> On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> > > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > 
> > > > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > > > 
> > > > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > > > 
> > > > > This compilation issue can be fixed by using the new routine
> > > > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > > > which also simplifies the code considerably.
> > > > 
> > > > 
> > > > Thanks for posting that! It certainly fixes that issue.
> > > 
> > > Acked-by?
> > 
> > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> 
> None of these are merged yet...

And it looks like you didn't CC the maintainer.

Also - how does this work if you have an older version of SuSE,
say SLES10?
> 
>  Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Konrad Rzeszutek Wilk]

On Fri, Feb 05, 2016 at 05:48:37PM -0800, Luis R. Rodriguez wrote:
> On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >
> > Here's a slew of build fixes as well as build warning fixes
> > required when using the latest build tools, at least gcc 5 and
> > binutils 2.25.0.
> 
> One good reason for some folks to get discouraged to work with Xen:

s/Xen/Any Open Source project/

Take a look in Documentation/SubmittingPatches, the " Don't get discouraged
- or impatient" section. It mentions 'pinging'.

> 
> Patches for fixes on builds last ages to get merged
> 
> In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
> offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
> it was probably not the right fix. Last year in November I provided
> what I think is a proper replacement set which I think addressed Jan's
> concerns.
> 
> ***Four*** months later and Xen still does not compile with the latest
> and greatest. I have to go digging out in my git basement somewhere
> some fixes I last used to build Xen to try to test some new
> features...

Odd it does compile for me - albeit I've had issues with the VNC
part which also needs another patch. But I hadn't had the chance to
see whether the patch would break builds on much older version of
distros.
> 
> What's up folks? How can this process be made smoother, did I do
> something wrong, what can I do to help better? What can you do to help
> ensure these types of things don't fall through the cracks.

ping? The same thing you would do on LKML.

> 
> [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/264183
> 
>   Luis

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote:
> > On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> > > > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > > 
> > > > > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > > > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > > > > 
> > > > > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > > > > 
> > > > > > This compilation issue can be fixed by using the new routine
> > > > > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > > > > which also simplifies the code considerably.
> > > > > 
> > > > > 
> > > > > Thanks for posting that! It certainly fixes that issue.
> > > > 
> > > > Acked-by?
> > > 
> > > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > None of these are merged yet...
> 
> And it looks like you didn't CC the maintainer.

mcgrof at garbanzo ~/devel/xen (git::staging)$ ./scripts/get_maintainer.pl ../xen-fixes/0002-proper-qemu-trad-gnutls.patch 
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Tim Deegan <tim@xen.org>
xen-devel at lists.xen.org

I missed Ian Jackson, Keir and Tim.

> Also - how does this work if you have an older version of SuSE,
> say SLES10?

Beats me. I just dealt with getting this to compile with what is current.
I kind of doubt what is in xen master or staging will end up in SLE10's
version of Xen too. If that had to happen people porting this to an old
library could just add a helper gnutls_priority_set_direct() wrapper to
do things the old way.

  Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote:
> > On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
> > > On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
> > > > On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
> > > > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > > > 
> > > > > > Using deprecate gnutls_*_set() triggers a failure to compile
> > > > > > with gnutls30-3.4.4, used on OpenSUSE factory:
> > > > > > 
> > > > > > ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
> > > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
> > > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
> > > > > > ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
> > > > > > 
> > > > > > This compilation issue can be fixed by using the new routine
> > > > > > gnutls_priority_set_direct() which replaces the deprecated calls
> > > > > > which also simplifies the code considerably.
> > > > > 
> > > > > 
> > > > > Thanks for posting that! It certainly fixes that issue.
> > > > 
> > > > Acked-by?
> > > 
> > > Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > 
> > None of these are merged yet...
> 
> And it looks like you didn't CC the maintainer.

mcgrof@garbanzo ~/devel/xen (git::staging)$ ./scripts/get_maintainer.pl ../xen-fixes/0002-proper-qemu-trad-gnutls.patch 
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Tim Deegan <tim@xen.org>
xen-devel@lists.xen.org

I missed Ian Jackson, Keir and Tim.

> Also - how does this work if you have an older version of SuSE,
> say SLES10?

Beats me. I just dealt with getting this to compile with what is current.
I kind of doubt what is in xen master or staging will end up in SLE10's
version of Xen too. If that had to happen people porting this to an old
library could just add a helper gnutls_priority_set_direct() wrapper to
do things the old way.

  Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Fri, Feb 05, 2016 at 10:52:01PM -0500, Konrad Rzeszutek Wilk wrote:
> On Fri, Feb 05, 2016 at 05:48:37PM -0800, Luis R. Rodriguez wrote:
> > On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> > <mcgrof@do-not-panic.com> wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > >
> > > Here's a slew of build fixes as well as build warning fixes
> > > required when using the latest build tools, at least gcc 5 and
> > > binutils 2.25.0.
> > 
> > One good reason for some folks to get discouraged to work with Xen:
> 
> s/Xen/Any Open Source project/
> 
> Take a look in Documentation/SubmittingPatches, the " Don't get discouraged
> - or impatient" section. It mentions 'pinging'.

I delays on pinging for new features, etc, things still being broken with
compiling the latest and greatest however is not.

> > Patches for fixes on builds last ages to get merged
> > 
> > In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
> > offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
> > it was probably not the right fix. Last year in November I provided
> > what I think is a proper replacement set which I think addressed Jan's
> > concerns.
> > 
> > ***Four*** months later and Xen still does not compile with the latest
> > and greatest. I have to go digging out in my git basement somewhere
> > some fixes I last used to build Xen to try to test some new
> > features...
> 
> Odd it does compile for me - albeit I've had issues with the VNC
> part which also needs another patch.

Is there an auto build test going on with different distros going ?
If not that might help.

> But I hadn't had the chance to
> see whether the patch would break builds on much older version of
> distros.

A static inline to define the new method in the old way of doing
things should suffice as well I think.

> > What's up folks? How can this process be made smoother, did I do
> > something wrong, what can I do to help better? What can you do to help
> > ensure these types of things don't fall through the cracks.
> 
> ping? The same thing you would do on LKML.

0 day build tests the kernel all the time, even if my patch gets
missed, after a few days other will immediately notice. These days
its extremely hard for me to build linux-next and have a build
issue.

I recommend we push on the momentum to see if we can piggy back
on doing regular 0 day build tests with Xen too if possible.

   Luis

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

> > Also - how does this work if you have an older version of SuSE,
> > say SLES10?
> 
> Beats me. I just dealt with getting this to compile with what is current.
> I kind of doubt what is in xen master or staging will end up in SLE10's
> version of Xen too. If that had to happen people porting this to an old

I build staging on Fedora Core 13 and then occasionally on OL5 and OL6.

> library could just add a helper gnutls_priority_set_direct() wrapper to
> do things the old way.

Any ideas on how to detect whether the wrapper should be used from
within the qemu-traditional code? Does the library have an programatic way
to expose this? (#ifdef machinery?)

> 
>   Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Konrad Rzeszutek Wilk]

> > Also - how does this work if you have an older version of SuSE,
> > say SLES10?
> 
> Beats me. I just dealt with getting this to compile with what is current.
> I kind of doubt what is in xen master or staging will end up in SLE10's
> version of Xen too. If that had to happen people porting this to an old

I build staging on Fedora Core 13 and then occasionally on OL5 and OL6.

> library could just add a helper gnutls_priority_set_direct() wrapper to
> do things the old way.

Any ideas on how to detect whether the wrapper should be used from
within the qemu-traditional code? Does the library have an programatic way
to expose this? (#ifdef machinery?)

> 
>   Luis

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Fri, Feb 05, 2016 at 11:12:36PM -0500, Konrad Rzeszutek Wilk wrote:
> > a library could just add a helper gnutls_priority_set_direct() wrapper to
> > do things the old way.
> 
> Any ideas on how to detect whether the wrapper should be used from
> within the qemu-traditional code? Does the library have an programatic way
> to expose this? (#ifdef machinery?)

Sorry no I do not deal with backporting userspace applications. Is it a
requirement for developers on Xen to figure this out? I though this
would be for the folks who productize.

  Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Fri, Feb 05, 2016 at 11:12:36PM -0500, Konrad Rzeszutek Wilk wrote:
> > a library could just add a helper gnutls_priority_set_direct() wrapper to
> > do things the old way.
> 
> Any ideas on how to detect whether the wrapper should be used from
> within the qemu-traditional code? Does the library have an programatic way
> to expose this? (#ifdef machinery?)

Sorry no I do not deal with backporting userspace applications. Is it a
requirement for developers on Xen to figure this out? I though this
would be for the folks who productize.

  Luis

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Doug Goldstein]

On 2/5/16 10:03 PM, Luis R. Rodriguez wrote:
> On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote:
>>> On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
>>>> On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
>>>>> On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
>>>>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>>>>
>>>>>>> Using deprecate gnutls_*_set() triggers a failure to compile
>>>>>>> with gnutls30-3.4.4, used on OpenSUSE factory:
>>>>>>>
>>>>>>> ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
>>>>>>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
>>>>>>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
>>>>>>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
>>>>>>>
>>>>>>> This compilation issue can be fixed by using the new routine
>>>>>>> gnutls_priority_set_direct() which replaces the deprecated calls
>>>>>>> which also simplifies the code considerably.
>>>>>>
>>>>>>
>>>>>> Thanks for posting that! It certainly fixes that issue.
>>>>>
>>>>> Acked-by?
>>>>
>>>> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>
>>> None of these are merged yet...
>>
>> And it looks like you didn't CC the maintainer.
> 
> mcgrof at garbanzo ~/devel/xen (git::staging)$ ./scripts/get_maintainer.pl ../xen-fixes/0002-proper-qemu-trad-gnutls.patch 
> Ian Campbell <ian.campbell@citrix.com>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Jan Beulich <jbeulich@suse.com>
> Keir Fraser <keir@xen.org>
> Tim Deegan <tim@xen.org>
> xen-devel at lists.xen.org
> 
> I missed Ian Jackson, Keir and Tim.
> 
>> Also - how does this work if you have an older version of SuSE,
>> say SLES10?
> 
> Beats me. I just dealt with getting this to compile with what is current.
> I kind of doubt what is in xen master or staging will end up in SLE10's
> version of Xen too. If that had to happen people porting this to an old
> library could just add a helper gnutls_priority_set_direct() wrapper to
> do things the old way.
> 
>   Luis
> 

I'd personally love to know what's the real minimum that needs to be
supported by Xen master/staging. I tried [1] to put a line in the sand
but that died. I'm also in the process on standing up some basic build
CI [2] and as part of that I would build on new stuff and build on the
oldest set that's supported.

[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03577.html
[2]
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00984.html

-- 
Doug Goldstein

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 959 bytes
Desc: OpenPGP digital signature
URL: <https://systeme.lip6.fr/pipermail/cocci/attachments/20160206/1c189064/attachment-0001.asc>

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Doug Goldstein]

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

On 2/5/16 10:03 PM, Luis R. Rodriguez wrote:
> On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Sat, Feb 06, 2016 at 02:44:54AM +0100, Luis R. Rodriguez wrote:
>>> On Wed, Nov 25, 2015 at 03:44:30PM -0500, Konrad Rzeszutek Wilk wrote:
>>>> On Wed, Nov 25, 2015 at 08:36:51PM +0100, Luis R. Rodriguez wrote:
>>>>> On Wed, Nov 25, 2015 at 09:53:27AM -0500, Konrad Rzeszutek Wilk wrote:
>>>>>> On Fri, Nov 20, 2015 at 09:47:45AM -0800, Luis R. Rodriguez wrote:
>>>>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>>>>
>>>>>>> Using deprecate gnutls_*_set() triggers a failure to compile
>>>>>>> with gnutls30-3.4.4, used on OpenSUSE factory:
>>>>>>>
>>>>>>> ../libqemu_common.a(vnc.o): In function `vnc_start_tls':
>>>>>>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
>>>>>>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
>>>>>>> ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
>>>>>>>
>>>>>>> This compilation issue can be fixed by using the new routine
>>>>>>> gnutls_priority_set_direct() which replaces the deprecated calls
>>>>>>> which also simplifies the code considerably.
>>>>>>
>>>>>>
>>>>>> Thanks for posting that! It certainly fixes that issue.
>>>>>
>>>>> Acked-by?
>>>>
>>>> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>>>
>>> None of these are merged yet...
>>
>> And it looks like you didn't CC the maintainer.
> 
> mcgrof@garbanzo ~/devel/xen (git::staging)$ ./scripts/get_maintainer.pl ../xen-fixes/0002-proper-qemu-trad-gnutls.patch 
> Ian Campbell <ian.campbell@citrix.com>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Jan Beulich <jbeulich@suse.com>
> Keir Fraser <keir@xen.org>
> Tim Deegan <tim@xen.org>
> xen-devel@lists.xen.org
> 
> I missed Ian Jackson, Keir and Tim.
> 
>> Also - how does this work if you have an older version of SuSE,
>> say SLES10?
> 
> Beats me. I just dealt with getting this to compile with what is current.
> I kind of doubt what is in xen master or staging will end up in SLE10's
> version of Xen too. If that had to happen people porting this to an old
> library could just add a helper gnutls_priority_set_direct() wrapper to
> do things the old way.
> 
>   Luis
> 

I'd personally love to know what's the real minimum that needs to be
supported by Xen master/staging. I tried [1] to put a line in the sand
but that died. I'm also in the process on standing up some basic build
CI [2] and as part of that I would build on new stuff and build on the
oldest set that's supported.

[1]
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03577.html
[2]
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00984.html

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

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

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Doug Goldstein]

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

On 2/5/16 10:07 PM, Luis R. Rodriguez wrote:
> On Fri, Feb 05, 2016 at 10:52:01PM -0500, Konrad Rzeszutek Wilk wrote:
>> On Fri, Feb 05, 2016 at 05:48:37PM -0800, Luis R. Rodriguez wrote:
>>> On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
>>> <mcgrof@do-not-panic.com> wrote:
>>>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>>>
>>>> Here's a slew of build fixes as well as build warning fixes
>>>> required when using the latest build tools, at least gcc 5 and
>>>> binutils 2.25.0.
>>>
>>> One good reason for some folks to get discouraged to work with Xen:
>>
>> s/Xen/Any Open Source project/
>>
>> Take a look in Documentation/SubmittingPatches, the " Don't get discouraged
>> - or impatient" section. It mentions 'pinging'.
> 
> I delays on pinging for new features, etc, things still being broken with
> compiling the latest and greatest however is not.
> 
>>> Patches for fixes on builds last ages to get merged
>>>
>>> In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
>>> offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
>>> it was probably not the right fix. Last year in November I provided
>>> what I think is a proper replacement set which I think addressed Jan's
>>> concerns.
>>>
>>> ***Four*** months later and Xen still does not compile with the latest
>>> and greatest. I have to go digging out in my git basement somewhere
>>> some fixes I last used to build Xen to try to test some new
>>> features...
>>
>> Odd it does compile for me - albeit I've had issues with the VNC
>> part which also needs another patch.
> 
> Is there an auto build test going on with different distros going ?
> If not that might help.

Trying to make that happen here:
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg00984.html

Currently its only on Ubuntu 14.04 but with a few different compilers.
I've got follow on work that adds CentOS and will show others how they
can easily add more.


> 
>> But I hadn't had the chance to
>> see whether the patch would break builds on much older version of
>> distros.
> 
> A static inline to define the new method in the old way of doing
> things should suffice as well I think.
> 
>>> What's up folks? How can this process be made smoother, did I do
>>> something wrong, what can I do to help better? What can you do to help
>>> ensure these types of things don't fall through the cracks.
>>
>> ping? The same thing you would do on LKML.
> 
> 0 day build tests the kernel all the time, even if my patch gets
> missed, after a few days other will immediately notice. These days
> its extremely hard for me to build linux-next and have a build
> issue.
> 
> I recommend we push on the momentum to see if we can piggy back
> on doing regular 0 day build tests with Xen too if possible.
> 
>    Luis

Got links to where this is run? I'm assuming its using Autotest [1]?

[1] https://autotest.github.io/

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

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

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Fengguang Wu]

Hi Doug,

> > 0 day build tests the kernel all the time, even if my patch gets
> > missed, after a few days other will immediately notice. These days
> > its extremely hard for me to build linux-next and have a build
> > issue.
> > 
> > I recommend we push on the momentum to see if we can piggy back
> > on doing regular 0 day build tests with Xen too if possible.
> > 
> >    Luis
> 
> Got links to where this is run? I'm assuming its using Autotest [1]?
> 
> [1] https://autotest.github.io/

The 0day test infrastructure is running in Intel OTC Shanghai site.
Most test scripts we run are available in the lkp-tests git tree,
for example, autotest:

        https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/tree/tests/autotest

The project home page is at

        https://01.org/lkp

The build test reports are archived in the kbuild-all mailing list:

        https://lists.01.org/pipermail/kbuild-all/2016-January/thread.html

The runtime test reports are archived in the lkp list:

        https://lists.01.org/pipermail/lkp/2016-January/thread.html

Thanks,
Fengguang

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Fri, 2016-02-05 at 17:48 -0800, Luis R. Rodriguez wrote:
> What's up folks? How can this process be made smoother, did I do
> something wrong, what can I do to help better?

When you first sent this series to Jan + me not copying the list you were
asked to send to the list _and_ to CC the appropriate maintainers.

When you resent you only added the xen-devel CC without adjusting the CC.
Jan pointed this out to you (as a subsequent reply to the original private
thread) and so I archived both threads in anticipation of a corrected
series being resent in the not to distant future.

CCing maintainers is part of the Xen workflow just as it is with Linux, I
don't think you would expect to send a random selection of e.g. arch/x86
and drivers/net fixes to Linus+GregKH and have anything useful happen to
them.

If you were a newbie to this sort of thing I would probably have kept a
closer eye out for a v3 and given you some guidance if it didn't
materialise in a week or two but I didn't think it would be necessary in
your case since I know you are familiar with this sort of thing from the
Linux world and your previous contributions to Xen.

FWIW I would also suggest sending fixes to different components (qemu-xen,
qemu-xentraditional, xen.git, mini-os.git) as different series, lest
someone read patch #1 and assume the whole series is against that component
rather than something they maintain.

And BTW when we say to copy the maintainers we mean the person/people
responsible for the component in Xen, not the upstream maintainers, e.g.
Stefano for qemu-xen not Peter Maydell. The xen.git MAINTAINERS file lists
the right people.

Ian.

>  What can you do to help
> ensure these types of things don't fall through the cracks.
> 
> [0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/264183
> 
>   Luis

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Jan Beulich]

>>> On 06.02.16 at 02:48, <mcgrof@suse.com> wrote:
> On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> <mcgrof@do-not-panic.com> wrote:
>> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>>
>> Here's a slew of build fixes as well as build warning fixes
>> required when using the latest build tools, at least gcc 5 and
>> binutils 2.25.0.
> 
> One good reason for some folks to get discouraged to work with Xen:
> 
> Patches for fixes on builds last ages to get merged
> 
> In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
> offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
> it was probably not the right fix. Last year in November I provided
> what I think is a proper replacement set which I think addressed Jan's
> concerns.

A link to your submission instead of Mark's, which has been given
feedback on, would have been more helpful.

> ***Four*** months later and Xen still does not compile with the latest
> and greatest. I have to go digging out in my git basement somewhere
> some fixes I last used to build Xen to try to test some new
> features...
> 
> What's up folks? How can this process be made smoother, did I do
> something wrong, what can I do to help better? What can you do to help
> ensure these types of things don't fall through the cracks.

Patch 1 should have gone through SeaBIOS and then a backport
should have been requested. Patch 2 should equally have gone
through upstream qemu, and then a backport be requested. I
won't continue for the other ones.

Neither (apart from 4 and 5, which do so indirectly, referencing
something that isn't even a repo) indicates (in the title) what
component it's against.

And nothing in the entire series seems to fall into my areas of
responsibility, so I can't see why both the original series and
this mail was addressed to me. 

Please - don't complain about things not getting accepted if
you don't even follow basic submission rules.

Jan

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Jan Beulich]

>>> On 06.02.16 at 05:03, <mcgrof@suse.com> wrote:
> On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> Also - how does this work if you have an older version of SuSE,
>> say SLES10?
> 
> Beats me. I just dealt with getting this to compile with what is current.
> I kind of doubt what is in xen master or staging will end up in SLE10's
> version of Xen too. If that had to happen people porting this to an old
> library could just add a helper gnutls_priority_set_direct() wrapper to
> do things the old way.

Looks like you misunderstand: The question isn't what products
code might end up in, but what platforms are supported for
building. Right now, building of Xen and tools still works on SLE10
(and e.g. gcc is documented to be usable far enough back), so
you should avoid breaking the build on such older platforms (or
if you can't avoid it, you should make this explicit).

Jan

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 03:54:05AM -0700, Jan Beulich wrote:
> >>> On 06.02.16 at 05:03, <mcgrof@suse.com> wrote:
> > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> >> Also - how does this work if you have an older version of SuSE,
> >> say SLES10?
> > 
> > Beats me. I just dealt with getting this to compile with what is current.
> > I kind of doubt what is in xen master or staging will end up in SLE10's
> > version of Xen too. If that had to happen people porting this to an old
> > library could just add a helper gnutls_priority_set_direct() wrapper to
> > do things the old way.
> 
> Looks like you misunderstand: The question isn't what products
> code might end up in, but what platforms are supported for
> building. Right now, building of Xen and tools still works on SLE10
> (and e.g. gcc is documented to be usable far enough back), so
> you should avoid breaking the build on such older platforms (or
> if you can't avoid it, you should make this explicit).

I did misunderstand the question, but the same question applies, are
we supposed to backport solutions for new libraries all the way down to
things such as SLE10? That's a pretty important requirements and it
by no means was clear as a requirement to me. Is full Xen compiling
on SLE10 as of today before these changes? Who's testing that? Why
SLE10 and not factory?

  Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 03:54:05AM -0700, Jan Beulich wrote:
> >>> On 06.02.16 at 05:03, <mcgrof@suse.com> wrote:
> > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
> >> Also - how does this work if you have an older version of SuSE,
> >> say SLES10?
> > 
> > Beats me. I just dealt with getting this to compile with what is current.
> > I kind of doubt what is in xen master or staging will end up in SLE10's
> > version of Xen too. If that had to happen people porting this to an old
> > library could just add a helper gnutls_priority_set_direct() wrapper to
> > do things the old way.
> 
> Looks like you misunderstand: The question isn't what products
> code might end up in, but what platforms are supported for
> building. Right now, building of Xen and tools still works on SLE10
> (and e.g. gcc is documented to be usable far enough back), so
> you should avoid breaking the build on such older platforms (or
> if you can't avoid it, you should make this explicit).

I did misunderstand the question, but the same question applies, are
we supposed to backport solutions for new libraries all the way down to
things such as SLE10? That's a pretty important requirements and it
by no means was clear as a requirement to me. Is full Xen compiling
on SLE10 as of today before these changes? Who's testing that? Why
SLE10 and not factory?

  Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Mon, Feb 08, 2016 at 09:58:23AM +0000, Ian Campbell wrote:
> On Fri, 2016-02-05 at 17:48 -0800, Luis R. Rodriguez wrote:
> > What's up folks? How can this process be made smoother, did I do
> > something wrong, what can I do to help better?
> 
> When you first sent this series to Jan + me not copying the list you were
> asked to send to the list _and_ to CC the appropriate maintainers.

Yeah I truly fat fingered that first series.

> When you resent you only added the xen-devel CC without adjusting the CC.
> Jan pointed this out to you (as a subsequent reply to the original private
> thread) and so I archived both threads in anticipation of a corrected
> series being resent in the not to distant future.

OK I messed up then. My bad, I though this series was posted properly and
failed to note that as the reply was in private and archived, and since
I was busy such fixes weren't posted again. Sorry for the noise.

> CCing maintainers is part of the Xen workflow just as it is with Linux, I
> don't think you would expect to send a random selection of e.g. arch/x86
> and drivers/net fixes to Linus+GregKH and have anything useful happen to
> them.

That's right.

> If you were a newbie to this sort of thing I would probably have kept a
> closer eye out for a v3 and given you some guidance if it didn't
> materialise in a week or two but I didn't think it would be necessary in
> your case since I know you are familiar with this sort of thing from the
> Linux world and your previous contributions to Xen.

No you're right, this just fell through the cracks. The surprising case of
things still being broken on modern tools however should raise a bit of
concern either by opensuse factory folks or by Xen build folks in general.
The issues with required target platfroms to build and if developers are
required to backport features for tools carried / forked is also a pretty
important and IMHO a heavy requirement.

> FWIW I would also suggest sending fixes to different components (qemu-xen,
> qemu-xentraditional, xen.git, mini-os.git) as different series, lest
> someone read patch #1 and assume the whole series is against that component
> rather than something they maintain.

OK thanks. Right Jan didn't read that cover letter so he was not ware of
the work I put into vetting if things were upstream or not.

> And BTW when we say to copy the maintainers we mean the person/people
> responsible for the component in Xen, not the upstream maintainers, e.g.
> Stefano for qemu-xen not Peter Maydell. The xen.git MAINTAINERS file lists
> the right people.

Sure, I do both though, first real upstream and then prod the Xen maintainers.
I take it scripts/get_maintainer.pl should work though? I tried it in a few
patches and it seemed to have worked

  Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Jan Beulich]

>>> On 09.02.16 at 16:46, <mcgrof@suse.com> wrote:
> On Tue, Feb 09, 2016 at 03:54:05AM -0700, Jan Beulich wrote:
>> >>> On 06.02.16 at 05:03, <mcgrof@suse.com> wrote:
>> > On Fri, Feb 05, 2016 at 10:45:54PM -0500, Konrad Rzeszutek Wilk wrote:
>> >> Also - how does this work if you have an older version of SuSE,
>> >> say SLES10?
>> > 
>> > Beats me. I just dealt with getting this to compile with what is current.
>> > I kind of doubt what is in xen master or staging will end up in SLE10's
>> > version of Xen too. If that had to happen people porting this to an old
>> > library could just add a helper gnutls_priority_set_direct() wrapper to
>> > do things the old way.
>> 
>> Looks like you misunderstand: The question isn't what products
>> code might end up in, but what platforms are supported for
>> building. Right now, building of Xen and tools still works on SLE10
>> (and e.g. gcc is documented to be usable far enough back), so
>> you should avoid breaking the build on such older platforms (or
>> if you can't avoid it, you should make this explicit).
> 
> I did misunderstand the question, but the same question applies, are
> we supposed to backport solutions for new libraries all the way down to
> things such as SLE10? That's a pretty important requirements and it
> by no means was clear as a requirement to me. Is full Xen compiling
> on SLE10 as of today before these changes? Who's testing that? Why
> SLE10 and not factory?

The requirement is not SLE10 in particular (just that it serves as a
good example), but "older distros" more generally, i.e. would as
well apply to the equivalent RHEL. For support reasons I have two
such systems left, and I do build and run Xen on them on a regular
but not very frequent basis (about once every two to three months).

Jan

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 01:08:13AM -0700, Jan Beulich wrote:
> >>> On 06.02.16 at 02:48, <mcgrof@suse.com> wrote:
> > On Fri, Nov 20, 2015 at 9:47 AM, Luis R. Rodriguez
> > <mcgrof@do-not-panic.com> wrote:
> >> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> >>
> >> Here's a slew of build fixes as well as build warning fixes
> >> required when using the latest build tools, at least gcc 5 and
> >> binutils 2.25.0.
> > 
> > One good reason for some folks to get discouraged to work with Xen:
> > 
> > Patches for fixes on builds last ages to get merged
> > 
> > In this case Mark Pryor <pryorm09@gmail.com> reported an issue and
> > offered a fix on October 8, 2015 [0]. That did not go in as Jan noted
> > it was probably not the right fix. Last year in November I provided
> > what I think is a proper replacement set which I think addressed Jan's
> > concerns.
> 
> A link to your submission instead of Mark's, which has been given
> feedback on, would have been more helpful.
> 
> > ***Four*** months later and Xen still does not compile with the latest
> > and greatest. I have to go digging out in my git basement somewhere
> > some fixes I last used to build Xen to try to test some new
> > features...
> > 
> > What's up folks? How can this process be made smoother, did I do
> > something wrong, what can I do to help better? What can you do to help
> > ensure these types of things don't fall through the cracks.
> 
> Patch 1 should have gone through SeaBIOS and then a backport
> should have been requested.

On the cover letter I explained I did the work to check upstream
and see if indeed what I'm doing is a backport and if not see
if I send it first upstream and then explain its a backport.
In cases where I found the change upstream I provide the
"Upstream sha1sum" at the top of the commit, which follows
the Linux stable backport practice given I saw no equivalent
practice on Xen backporting and figured this was important.

> Patch 2 should equally have gone
> through upstream qemu, and then a backport be requested. I
> won't continue for the other ones.

This one did not have a respective backport commit, instead
the new API was explicitly used via commit d321e1e5268:

commit d321e1e5268103af616ec4c623c6326c3f7c7bc7
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Mon Mar 2 17:23:31 2015 +0000

    crypto: introduce new module for handling TLS sessions

And then later qemu was changed to use the new interface
via commit 3e305e4a4752f:

commit 3e305e4a4752f70c0b5c3cf5b43ec957881714f7
Author: Daniel P. Berrange <berrange@redhat.com>
Date:   Thu Aug 6 14:39:32 2015 +0100

    ui: convert VNC server to use QCryptoTLSSession

So unless we embrace the new TLS module we can't directly
backport the upstream solution.

I have similar explanations on the patches / cover letter.
At times when I saw the upstream commit lacked a proper
commit log I actually went to lengths to explain actual
real impact of not applying the changes. This should
help people looking to cherry pick important things to
stable branches.

> 
> Neither (apart from 4 and 5, which do so indirectly, referencing
> something that isn't even a repo) indicates (in the title) what
> component it's against.

I did explain this on the cover letter but I could have done a better job by
splitting things. I could have CC'd more maintainers aas well.

> And nothing in the entire series seems to fall into my areas of
> responsibility, so I can't see why both the original series and
> this mail was addressed to me. 

OK.

> Please - don't complain about things not getting accepted if
> you don't even follow basic submission rules.

The realization that compilation is not working for some modern
tools, in particular for OpenSUSE factory for a long time without
it being addressed is a bit concerning.

  Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Tue, 2016-02-09 at 17:09 +0100, Luis R. Rodriguez wrote:
> The realization that compilation is not working for some modern
> tools, in particular for OpenSUSE factory for a long time without
> it being addressed is a bit concerning.

I don't know what OpenSUSE factory is building but Xen 4.6.0 built in
Debian just fine using gcc 5 and more recently due to https://bugs.debian.o
rg/cgi-bin/bugreport.cgi?bug=812166 I found and fixed all the issues which
I could find with building gcc 6.

Ian.

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Tue, 2016-02-09 at 16:56 +0100, Luis R. Rodriguez wrote:
> 
> No you're right, this just fell through the cracks. The surprising case of
> things still being broken on modern tools however should raise a bit of
> concern either by opensuse factory folks or by Xen build folks in general.

AFAIK both Xen 4.6 and Xen unstable build fine with gcc5 now, and unstable
does so even with gcc6.

> The issues with required target platfroms to build and if developers are
> required to backport features for tools carried / forked is also a pretty
> important and IMHO a heavy requirement.

I'm not sure what this means, but Xen surely doesn't require anyone to
backport toolchains.

> > FWIW I would also suggest sending fixes to different components (qemu-xen,
> > qemu-xentraditional, xen.git, mini-os.git) as different series, lest
> > someone read patch #1 and assume the whole series is against that component
> > rather than something they maintain.
> 
> OK thanks. Right Jan didn't read that cover letter so he was not ware of
> the work I put into vetting if things were upstream or not.

This seems like a non-sequitor compared to the paragraph quoted above it
(i.e. I'm not sure what upstream vs not has to do with sending unrelated
patches against different components in different series).

> > And BTW when we say to copy the maintainers we mean the person/people
> > responsible for the component in Xen, not the upstream maintainers,
> > e.g.
> > Stefano for qemu-xen not Peter Maydell. The xen.git MAINTAINERS file
> > lists
> > the right people.
> 
> Sure, I do both though, first real upstream and then prod the Xen maintainers.
> I take it scripts/get_maintainer.pl should work though? I tried it in a few
> patches and it seemed to have worked

I wouldn't bet on it always doing the right thing with 3rd party components
like qemu-xen.

Ian.

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 04:22:01PM +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 17:09 +0100, Luis R. Rodriguez wrote:
> > The realization that compilation is not working for some modern
> > tools, in particular for OpenSUSE factory for a long time without
> > it being addressed is a bit concerning.
> 
> I don't know what OpenSUSE factory is building but Xen 4.6.0 built in
> Debian just fine using gcc 5 

Odd, I have a debian testing box I also build against and I also have issues
building there. The latest ones now:

The error log from compiling the libSDL test is:
/tmp/qemu-conf--5604-.c:1:17: fatal error: SDL.h: No such file or directory
compilation terminated.
qemu successfuly configured for Xen qemu-dm build
make[3]: Entering directory '/home/mcgrof/devel/xen/tools/qemu-xen-traditional-dir-remote'

And then:

=== PCI passthrough capability has been enabled ===
  CC    qemu-nbd.o
In file included from ./xen-config-host.h:19:0,
                 from ./config-host.h:18,
                 from ./qemu-common.h:33,
                 from qemu-nbd.c:20:
/usr/local/include/xenctrl.h:1229:9: error: unknown type name ‘xen_sysctl_topologyinfo_t’
 typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;


> and more recently due to https://bugs.debian.o
> rg/cgi-bin/bugreport.cgi?bug=812166 I found and fixed all the issues which
> I could find with building gcc 6.

Nice. Good to know.

 Luis

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

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Olaf Hering]

On Fri, Feb 05, Konrad Rzeszutek Wilk wrote:

> Also - how does this work if you have an older version of SuSE,
> say SLES10?

SLE10 is out of scope since along time already.
This patch for current gnutls is already in qemu mainline.
f40d55081667a716312b9a8b6e13835c4074f56b
7d2a929feba319c18603e324b1750830d6c8b7a1

I sent this already months/years ago.
Debian Stale compiles fine, so why bother...


Olaf

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Tue, 2016-02-09 at 17:30 +0100, Luis R. Rodriguez wrote:
> On Tue, Feb 09, 2016 at 04:22:01PM +0000, Ian Campbell wrote:
> > On Tue, 2016-02-09 at 17:09 +0100, Luis R. Rodriguez wrote:
> > > The realization that compilation is not working for some modern
> > > tools, in particular for OpenSUSE factory for a long time without
> > > it being addressed is a bit concerning.
> > 
> > I don't know what OpenSUSE factory is building but Xen 4.6.0 built in
> > Debian just fine using gcc 5 
> 
> Odd, I have a debian testing box I also build against and I also have
> issues
> building there. The latest ones now:
> 
> The error log from compiling the libSDL test is:
> /tmp/qemu-conf--5604-.c:1:17: fatal error: SDL.h: No such file or directory

Missing dev package, not a gcc 5 vs 6 issue.

> compilation terminated.
> qemu successfuly configured for Xen qemu-dm build
> make[3]: Entering directory '/home/mcgrof/devel/xen/tools/qemu-xen-
> traditional-dir-remote'
> 
> And then:
> 
> === PCI passthrough capability has been enabled ===
>   CC    qemu-nbd.o
> In file included from ./xen-config-host.h:19:0,
>                  from ./config-host.h:18,
>                  from ./qemu-common.h:33,
>                  from qemu-nbd.c:20:
> /usr/local/include/xenctrl.h:1229:9: error: unknown type name ‘xen_sysctl_topologyinfo_t’
>  typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;

If this was building from xen.git then the problem would appear to be that
it is picking up headers from /usr/local instead of the ones from in tree
(i.e. the libraries its just built).

However more information about your build environment and commands would be
needed to say for sure.

Ian.

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 04:26:36PM +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 16:56 +0100, Luis R. Rodriguez wrote:
> > 
> > No you're right, this just fell through the cracks. The surprising case of
> > things still being broken on modern tools however should raise a bit of
> > concern either by opensuse factory folks or by Xen build folks in general.
> 
> AFAIK both Xen 4.6 and Xen unstable build fine with gcc5 now, and unstable
> does so even with gcc6.

It would seem the possible remaining issues are the library requirements.

> > The issues with required target platfroms to build and if developers are
> > required to backport features for tools carried / forked is also a pretty
> > important and IMHO a heavy requirement.
> 
> I'm not sure what this means, but Xen surely doesn't require anyone to
> backport toolchains.

So if a new gnutls library deprecated a set of routines which are only
available using a new set of APIs, one does not have to provide the stub to
backport this for the old gnutls library? In this case the upstream project
required a  new module which uses the new API, so another option is to upgrade
the qemu release embraced by xen.

> > > FWIW I would also suggest sending fixes to different components (qemu-xen,
> > > qemu-xentraditional, xen.git, mini-os.git) as different series, lest
> > > someone read patch #1 and assume the whole series is against that component
> > > rather than something they maintain.
> > 
> > OK thanks. Right Jan didn't read that cover letter so he was not ware of
> > the work I put into vetting if things were upstream or not.
> 
> This seems like a non-sequitor compared to the paragraph quoted above it
> (i.e. I'm not sure what upstream vs not has to do with sending unrelated
> patches against different components in different series).

It was an example of how the series failed to be properly split and because I
didn't send things separately it was not clear to different maintainers the
status of each patch with respect to the upstream project.

> > > And BTW when we say to copy the maintainers we mean the person/people
> > > responsible for the component in Xen, not the upstream maintainers,
> > > e.g.
> > > Stefano for qemu-xen not Peter Maydell. The xen.git MAINTAINERS file
> > > lists
> > > the right people.
> > 
> > Sure, I do both though, first real upstream and then prod the Xen maintainers.
> > I take it scripts/get_maintainer.pl should work though? I tried it in a few
> > patches and it seemed to have worked
> 
> I wouldn't bet on it always doing the right thing with 3rd party components
> like qemu-xen.

Hrm, so how can I get the proper maintainer ? For my case I need to split this
series up into 5 or 6 series for 5 separate trees:

1. tools/firmware/seabios-dir-remote/
2. tools/qemu-xen-traditional-dir-remote/
3. tools/qemu-xen-dir-remote/
4. extras/mini-os-remote/
5. top level xen:
	5a. stubdom
	5a. vtpm

Since I can't seem to rely on scripts/get_maintainer.pl I want to make sure I get
this right this time around.

  Luis

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 05:36:18PM +0100, Olaf Hering wrote:
> On Fri, Feb 05, Konrad Rzeszutek Wilk wrote:
> 
> > Also - how does this work if you have an older version of SuSE,
> > say SLES10?
> 
> SLE10 is out of scope since along time already.
> This patch for current gnutls is already in qemu mainline.
> f40d55081667a716312b9a8b6e13835c4074f56b
> 7d2a929feba319c18603e324b1750830d6c8b7a1
> 
> I sent this already months/years ago.
> Debian Stale compiles fine, so why bother...

Thanks so it seems the other option is to bump the release, can that
be decided? What's the process for deciding that?

  Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 05:36:18PM +0100, Olaf Hering wrote:
> On Fri, Feb 05, Konrad Rzeszutek Wilk wrote:
> 
> > Also - how does this work if you have an older version of SuSE,
> > say SLES10?
> 
> SLE10 is out of scope since along time already.
> This patch for current gnutls is already in qemu mainline.
> f40d55081667a716312b9a8b6e13835c4074f56b
> 7d2a929feba319c18603e324b1750830d6c8b7a1
> 
> I sent this already months/years ago.
> Debian Stale compiles fine, so why bother...

Thanks so it seems the other option is to bump the release, can that
be decided? What's the process for deciding that?

  Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Tue, Feb 09, 2016 at 04:39:20PM +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 17:30 +0100, Luis R. Rodriguez wrote:
> > On Tue, Feb 09, 2016 at 04:22:01PM +0000, Ian Campbell wrote:
> > > On Tue, 2016-02-09 at 17:09 +0100, Luis R. Rodriguez wrote:
> > > > The realization that compilation is not working for some modern
> > > > tools, in particular for OpenSUSE factory for a long time without
> > > > it being addressed is a bit concerning.
> > > 
> > > I don't know what OpenSUSE factory is building but Xen 4.6.0 built in
> > > Debian just fine using gcc 5 
> > 
> > Odd, I have a debian testing box I also build against and I also have
> > issues
> > building there. The latest ones now:
> > 
> > The error log from compiling the libSDL test is:
> > /tmp/qemu-conf--5604-.c:1:17: fatal error: SDL.h: No such file or directory
> 
> Missing dev package, not a gcc 5 vs 6 issue.

Its odd considering I had been building Xen for a long time without such dev
packages. Perhaps we don't propagate --disable-gfx-check for on
tools/qemu-xen-traditional-dir if no such sdl dev packages is found.

Should it ? All I know is this used to build.

The configure error there is:

ERROR: QEMU requires SDL or Cocoa for graphical output
To build QEMU without graphical output configure with --disable-gfx-check
Note that this will disable all output from the virtual graphics card
except through VNC or curses.

> > compilation terminated.
> > qemu successfuly configured for Xen qemu-dm build
> > make[3]: Entering directory '/home/mcgrof/devel/xen/tools/qemu-xen-
> > traditional-dir-remote'
> > 
> > And then:
> > 
> > === PCI passthrough capability has been enabled ===
> >   CC    qemu-nbd.o
> > In file included from ./xen-config-host.h:19:0,
> >                  from ./config-host.h:18,
> >                  from ./qemu-common.h:33,
> >                  from qemu-nbd.c:20:
> > /usr/local/include/xenctrl.h:1229:9: error: unknown type name ‘xen_sysctl_topologyinfo_t’
> >  typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;
> 
> If this was building from xen.git then the problem would appear to be that
> it is picking up headers from /usr/local instead of the ones from in tree
> (i.e. the libraries its just built).

Hrm, I don't typically build things which are custom other than Xen on this
system. Is this an issue ? Should we be picking up the local Xen directory for
header stuff ? Could this perhaps be a dependency issue with a make install
needing headers first prior to building another package? I really don't
build custom stuff here other than Xen, and I never use a custom prefix.

> However more information about your build environment and commands would be
> needed to say for sure.

Debian testing. The only thing I do a custom install with is Xen. So if it
has old headers it might be from previous manual installs.

  Luis

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

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Olaf Hering]

On Tue, Feb 09, Luis R. Rodriguez wrote:

> Thanks so it seems the other option is to bump the release, can that
> be decided? What's the process for deciding that?

Which release should be bumped?

Olaf

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Dario Faggioli]

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

On Tue, 2016-02-09 at 16:22 +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 17:09 +0100, Luis R. Rodriguez wrote:
> > The realization that compilation is not working for some modern
> > tools, in particular for OpenSUSE factory for a long time without
> > it being addressed is a bit concerning.
> 
> I don't know what OpenSUSE factory is building but Xen 4.6.0 built in
> Debian just fine using gcc 5 and more recently due to https://bugs.de
> bian.o
> rg/cgi-bin/bugreport.cgi?bug=812166 I found and fixed all the issues
> which
> I could find with building gcc 6.
> 
Just FTR, I do my day to day development and testing on Debian
unstable, which means I build (several times a day) without any issue
with (right now):

 gcc version 5.3.1 20160101 (Debian 5.3.1-5)

and:

$ apt-cache policy binutils
binutils:
  Installed: 2.25.90.20160101-1
  Candidate: 2.25.90.20160101-1
  Version table:
 *** 2.25.90.20160101-1 500
        500 http://ftp.it.debian.org/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

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

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Feb 09, Luis R. Rodriguez wrote:
>
>> Thanks so it seems the other option is to bump the release, can that
>> be decided? What's the process for deciding that?
>
> Which release should be bumped?

In so far as TLS is concerned:

mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
f40d55081667a716312b9a8b6e13835c4074f56b
v1.0-rc0~325

mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
7d2a929feba319c18603e324b1750830d6c8b7a1
v1.5.0-rc0~660

mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains d321e1e526810
v2.5.0-rc0~125^2~2

As for the other fix I backported for the existing release carried:

mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
98d23704138e0be17a3ed9eb2631077bf92cc028
v1.1-rc0~785

I wanted to see what is the current version on Xen for
qemu-xen-traditional-dir-remote thing, is this the right way to check
what version is on /tools/qemu-xen-traditional-dir-remote ?

mcgrof at ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
(git::dummy)$ cat VERSION
0.10.2

If so.. I'm scared.

 Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Tue, Feb 09, Luis R. Rodriguez wrote:
>
>> Thanks so it seems the other option is to bump the release, can that
>> be decided? What's the process for deciding that?
>
> Which release should be bumped?

In so far as TLS is concerned:

mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
f40d55081667a716312b9a8b6e13835c4074f56b
v1.0-rc0~325

mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
7d2a929feba319c18603e324b1750830d6c8b7a1
v1.5.0-rc0~660

mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains d321e1e526810
v2.5.0-rc0~125^2~2

As for the other fix I backported for the existing release carried:

mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
98d23704138e0be17a3ed9eb2631077bf92cc028
v1.1-rc0~785

I wanted to see what is the current version on Xen for
qemu-xen-traditional-dir-remote thing, is this the right way to check
what version is on /tools/qemu-xen-traditional-dir-remote ?

mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
(git::dummy)$ cat VERSION
0.10.2

If so.. I'm scared.

 Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Tue, Feb 9, 2016 at 8:53 AM, Luis R. Rodriguez <mcgrof@suse.com> wrote:
>> Missing dev package, not a gcc 5 vs 6 issue.
>
> Its odd considering I had been building Xen for a long time without such dev
> packages. Perhaps we don't propagate --disable-gfx-check for on
> tools/qemu-xen-traditional-dir if no such sdl dev packages is found.
>
> Should it ? All I know is this used to build.
>
> The configure error there is:
>
> ERROR: QEMU requires SDL or Cocoa for graphical output
> To build QEMU without graphical output configure with --disable-gfx-check
> Note that this will disable all output from the virtual graphics card
> except through VNC or curses.

FWIW, the packag elibsdl-console-dev

did the trick on debian.

 Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Luis R. Rodriguez]

On Tue, Feb 9, 2016 at 8:39 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> And then:
>>
>> === PCI passthrough capability has been enabled ===
>>   CC    qemu-nbd.o
>> In file included from ./xen-config-host.h:19:0,
>>                  from ./config-host.h:18,
>>                  from ./qemu-common.h:33,
>>                  from qemu-nbd.c:20:
>> /usr/local/include/xenctrl.h:1229:9: error: unknown type name ‘xen_sysctl_topologyinfo_t’
>>  typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;
>
> If this was building from xen.git then the problem would appear to be that
> it is picking up headers from /usr/local instead of the ones from in tree
> (i.e. the libraries its just built).

All the stuff in /usr/local was Xen related, so I rm -rf'd it, then
started a fresh build. It now fails with the following on a debian
testing with all the packages updated to today's latest.

make[4]: Entering directory
'/home/mcgrof/devel/xen/tools/qemu-xen-traditional-dir-remote'
=== PCI passthrough capability has been enabled ===
  CC    qemu-nbd.o
  CC    qemu-tool.o
  CC    osdep.o
  CC    cutils.o
In file included from config-host.h:20:0,
                 from osdep.c:25:
xen-config-host.h:19:21: fatal error: xenctrl.h: No such file or directory
compilation terminated.

If I just cd into that directory (tools/qemu-xen-traditional-dir/),
run ./configure and build it fails with:

mcgrof@garbanzo ~/devel/xen/tools/qemu-xen-traditional-dir (git::dummy)$ make
  LINK  qemu-nbd
  LINK  qemu-img
  CC    net.o
In file included from net.c:104:0:
/home/mcgrof/devel/xen/tools/qemu-xen-traditional-dir/slirp/libslirp.h:8:1:
error: invalid use of ‘restrict’
 void slirp_init(int restrict, char *special_ip);
 ^
/home/mcgrof/devel/xen/tools/qemu-xen-traditional-dir/slirp/libslirp.h:8:1:
error: invalid use of ‘restrict’
net.c: In function ‘net_tap_shutdown_all’:
net.c:1992:37: warning: unused variable ‘ioh’ [-Wunused-variable]
     struct IOHandlerRecord **pioh, *ioh;
                                     ^
net.c:1992:30: warning: unused variable ‘pioh’ [-Wunused-variable]
     struct IOHandlerRecord **pioh, *ioh;
                              ^
/home/mcgrof/devel/xen/tools/qemu-xen-traditional-dir/rules.mak:3:
recipe for target 'net.o' failed
make: *** [net.o] Error 1

I can probably fix this but if people are considering upgrading --
well my effort is pointless. The above seem to be related to gcc
upgrade. How is it only I'm running into this?

If I git clean -f -x -d, cd to the main home dir of xen, then git
clean -f -x -d, then ./configure and a fresh make world it fails on
the same failure on not finding xenctrl.h again.

:(

 Luis

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

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Tue, 2016-02-09 at 17:39 +0100, Luis R. Rodriguez wrote:
> 
> > I wouldn't bet on it always doing the right thing with 3rd party components
> > like qemu-xen.
> 
> Hrm, so how can I get the proper maintainer ? For my case I need to split this
> series up into 5 or 6 series for 5 separate trees:
> 
> 1. tools/firmware/seabios-dir-remote/
> 2. tools/qemu-xen-traditional-dir-remote/
> 3. tools/qemu-xen-dir-remote/
> 4. extras/mini-os-remote/
> 5. top level xen:
> 	5a. stubdom
> 	5a. vtpm
> 
> Since I can't seem to rely on scripts/get_maintainer.pl I want to make sure I get
> this right this time around.

They are listed in xen.git:MAINTAINERS, I just don't think I would rely on
get_maintainer.pl to pick out the correct entries.

Ian.

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Tue, 2016-02-09 at 17:53 +0100, Luis R. Rodriguez wrote:
> 
> > > === PCI passthrough capability has been enabled ===
> > >   CC    qemu-nbd.o
> > > In file included from ./xen-config-host.h:19:0,
> > >                  from ./config-host.h:18,
> > >                  from ./qemu-common.h:33,
> > >                  from qemu-nbd.c:20:
> > > /usr/local/include/xenctrl.h:1229:9: error: unknown type name ‘xen_sysctl_topologyinfo_t’
> > >  typedef xen_sysctl_topologyinfo_t xc_topologyinfo_t;
> > 
> > If this was building from xen.git then the problem would appear to be that
> > it is picking up headers from /usr/local instead of the ones from in tree
> > (i.e. the libraries its just built).
> 
> Hrm, I don't typically build things which are custom other than Xen on this
> system. Is this an issue ? Should we be picking up the local Xen directory for
> header stuff ? Could this perhaps be a dependency issue with a make install
> needing headers first prior to building another package? I really don't
> build custom stuff here other than Xen, and I never use a custom prefix.

The xen.git build system has been arranged such that the presence of xen
headers anywhere else (including in /usr/local) shouldn't be an issue,
since things should always be picked up from xen.git first.

However, maybe you are building qemu independently outside of the Xen build
system, it's not entirely clear. If that is the case then you do of course
need to "make install" Xen first (and/or do things with CFLAGS/LDFLAGS so
the QEMU build can find the Xen bits).

That uncertainty is why I asked:

> > However more information about your build environment and commands would be
> > needed to say for sure.

With which I was hoping you would describe clearly which repositories you
were building and which commands you were running in each.

Ian.

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

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Ian Campbell]

On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote:
> On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > On Tue, Feb 09, Luis R. Rodriguez wrote:
> > 
> > > Thanks so it seems the other option is to bump the release, can that
> > > be decided? What's the process for deciding that?
> > 
> > Which release should be bumped?
> 
> In so far as TLS is concerned:
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> f40d55081667a716312b9a8b6e13835c4074f56b
> v1.0-rc0~325
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> 7d2a929feba319c18603e324b1750830d6c8b7a1
> v1.5.0-rc0~660
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> d321e1e526810
> v2.5.0-rc0~125^2~2
> 
> As for the other fix I backported for the existing release carried:
> 
> mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> 98d23704138e0be17a3ed9eb2631077bf92cc028
> v1.1-rc0~785
> 
> I wanted to see what is the current version on Xen for
> qemu-xen-traditional-dir-remote thing, is this the right way to check
> what version is on /tools/qemu-xen-traditional-dir-remote ?
> 
> mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
> (git::dummy)$ cat VERSION
> 0.10.2
> 
> If so.. I'm scared.

qemu-xen-traditional Device Model is the old Xen fork which is maintained
only in order to support old VMs which expect the hardware environment
provided by that old version of QEMU.

The default Device Model since Xen 4.3 has been "qemu-xen", which is our
name for QEMU upstream. Xen 4.6 shipped with a bundled QEMU 2.2.1, but
users (and distros) are free to supply their own (see configure's --with-
system-qemu option) instead.

Hopefully it is clear therefore why just upgrading qemu-xen-traditional to
a newer QEMU is not an option (or rather, that already exists and is the
default via qemu-xen)

If you aren't interested in supporting VMs installed on very old versions
of Xen then it would be reasonable to:
    ./configure --disable-qemu-traditional
and avoid it all together.

So far as making qemu-xen-trad compatible with gcc5 while still retaining
support for building on the oldest platforms we want to support (whatever
those are) I have no real opinion, but it seems some sort of
abstraction/shim layer would be needed to satisfy both cases.

Ian.

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Ian Campbell]

On Tue, 2016-02-09 at 21:44 -0800, Luis R. Rodriguez wrote:
> If I just cd into that directory (tools/qemu-xen-traditional-dir/),
> run ./configure and build it fails with:

This doesn't work/isn't supported. The Xen build system includes support
for recursing properly into qemu-xen-traditional-dir (see tools/Makefile
and tools/Rules.mk) which you need to use.

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Feb 10, 2016 at 09:46:30AM +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote:
> > On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Tue, Feb 09, Luis R. Rodriguez wrote:
> > > 
> > > > Thanks so it seems the other option is to bump the release, can that
> > > > be decided? What's the process for deciding that?
> > > 
> > > Which release should be bumped?
> > 
> > In so far as TLS is concerned:
> > 
> > mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
> > f40d55081667a716312b9a8b6e13835c4074f56b
> > v1.0-rc0~325
> > 
> > mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
> > 7d2a929feba319c18603e324b1750830d6c8b7a1
> > v1.5.0-rc0~660
> > 
> > mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
> > d321e1e526810
> > v2.5.0-rc0~125^2~2
> > 
> > As for the other fix I backported for the existing release carried:
> > 
> > mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
> > 98d23704138e0be17a3ed9eb2631077bf92cc028
> > v1.1-rc0~785
> > 
> > I wanted to see what is the current version on Xen for
> > qemu-xen-traditional-dir-remote thing, is this the right way to check
> > what version is on /tools/qemu-xen-traditional-dir-remote ?
> > 
> > mcgrof at ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
> > (git::dummy)$ cat VERSION
> > 0.10.2
> > 
> > If so.. I'm scared.
> 
> qemu-xen-traditional Device Model is the old Xen fork which is maintained
> only in order to support old VMs which expect the hardware environment
> provided by that old version of QEMU.
> 
> The default Device Model since Xen 4.3 has been "qemu-xen", which is our
> name for QEMU upstream. Xen 4.6 shipped with a bundled QEMU 2.2.1, but
> users (and distros) are free to supply their own (see configure's --with-
> system-qemu option) instead.
> 
> Hopefully it is clear therefore why just upgrading qemu-xen-traditional to
> a newer QEMU is not an option (or rather, that already exists and is the
> default via qemu-xen)
> 
> If you aren't interested in supporting VMs installed on very old versions
> of Xen then it would be reasonable to:
>     ./configure --disable-qemu-traditional
> and avoid it all together.
> 
> So far as making qemu-xen-trad compatible with gcc5 while still retaining
> support for building on the oldest platforms we want to support (whatever
> those are) I have no real opinion, but it seems some sort of
> abstraction/shim layer would be needed to satisfy both cases.

Thanks for the details! If there is no proactive mechanism to scrape for
cherry picks for fixes or huge interest to keep it compatible with latest
compilers qemu-xen-traditional seems to be more of a liability than a
helper, would it be too irrational to propose to just burry it and mark
it as no longer supported?

  Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Feb 10, 2016 at 09:46:30AM +0000, Ian Campbell wrote:
> On Tue, 2016-02-09 at 19:04 -0800, Luis R. Rodriguez wrote:
> > On Tue, Feb 9, 2016 at 10:23 AM, Olaf Hering <olaf@aepfle.de> wrote:
> > > On Tue, Feb 09, Luis R. Rodriguez wrote:
> > > 
> > > > Thanks so it seems the other option is to bump the release, can that
> > > > be decided? What's the process for deciding that?
> > > 
> > > Which release should be bumped?
> > 
> > In so far as TLS is concerned:
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > f40d55081667a716312b9a8b6e13835c4074f56b
> > v1.0-rc0~325
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > 7d2a929feba319c18603e324b1750830d6c8b7a1
> > v1.5.0-rc0~660
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > d321e1e526810
> > v2.5.0-rc0~125^2~2
> > 
> > As for the other fix I backported for the existing release carried:
> > 
> > mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
> > 98d23704138e0be17a3ed9eb2631077bf92cc028
> > v1.1-rc0~785
> > 
> > I wanted to see what is the current version on Xen for
> > qemu-xen-traditional-dir-remote thing, is this the right way to check
> > what version is on /tools/qemu-xen-traditional-dir-remote ?
> > 
> > mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote
> > (git::dummy)$ cat VERSION
> > 0.10.2
> > 
> > If so.. I'm scared.
> 
> qemu-xen-traditional Device Model is the old Xen fork which is maintained
> only in order to support old VMs which expect the hardware environment
> provided by that old version of QEMU.
> 
> The default Device Model since Xen 4.3 has been "qemu-xen", which is our
> name for QEMU upstream. Xen 4.6 shipped with a bundled QEMU 2.2.1, but
> users (and distros) are free to supply their own (see configure's --with-
> system-qemu option) instead.
> 
> Hopefully it is clear therefore why just upgrading qemu-xen-traditional to
> a newer QEMU is not an option (or rather, that already exists and is the
> default via qemu-xen)
> 
> If you aren't interested in supporting VMs installed on very old versions
> of Xen then it would be reasonable to:
>     ./configure --disable-qemu-traditional
> and avoid it all together.
> 
> So far as making qemu-xen-trad compatible with gcc5 while still retaining
> support for building on the oldest platforms we want to support (whatever
> those are) I have no real opinion, but it seems some sort of
> abstraction/shim layer would be needed to satisfy both cases.

Thanks for the details! If there is no proactive mechanism to scrape for
cherry picks for fixes or huge interest to keep it compatible with latest
compilers qemu-xen-traditional seems to be more of a liability than a
helper, would it be too irrational to propose to just burry it and mark
it as no longer supported?

  Luis

Re: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Olaf Hering]

On Wed, Feb 10, Luis R. Rodriguez wrote:

> cherry picks for fixes or huge interest to keep it compatible with latest
> compilers qemu-xen-traditional seems to be more of a liability than a

Hey, this is about gnutls, not gcc!

Olaf

[Cocci] [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Feb 10, 2016 at 7:44 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Wed, Feb 10, Luis R. Rodriguez wrote:
>
>> cherry picks for fixes or huge interest to keep it compatible with latest
>> compilers qemu-xen-traditional seems to be more of a liability than a
>
> Hey, this is about gnutls, not gcc!

Actually no, I also had backported another fix which I submitted part
of this series, and it is present as of this release:

mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
98d23704138e0be17a3ed9eb2631077bf92cc028
v1.1-rc0~785

How are fixes of interested backported regularly for this to make it
reasonable to at least keep this as a viable option which at least
compiles? Only compiling is one thing, how are security fixes
backported proactively?

 Luis

Re: [Xen-devel] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

On Wed, Feb 10, 2016 at 7:44 AM, Olaf Hering <olaf@aepfle.de> wrote:
> On Wed, Feb 10, Luis R. Rodriguez wrote:
>
>> cherry picks for fixes or huge interest to keep it compatible with latest
>> compilers qemu-xen-traditional seems to be more of a liability than a
>
> Hey, this is about gnutls, not gcc!

Actually no, I also had backported another fix which I submitted part
of this series, and it is present as of this release:

mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
98d23704138e0be17a3ed9eb2631077bf92cc028
v1.1-rc0~785

How are fixes of interested backported regularly for this to make it
reasonable to at least keep this as a viable option which at least
compiles? Only compiling is one thing, how are security fixes
backported proactively?

 Luis

Re: [PATCH 0/9] xen: build fixes with gcc5 and binutils 2.25.0

[Olaf Hering]

On Tue, Feb 09, Luis R. Rodriguez wrote:

> The error log from compiling the libSDL test is:
> /tmp/qemu-conf--5604-.c:1:17: fatal error: SDL.h: No such file or directory

This is just the configure test, it can be ignored.

Olaf

[Cocci] [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Using deprecate gnutls_*_set() triggers a failure to compile
with gnutls30-3.4.4, used on OpenSUSE factory:

../libqemu_common.a(vnc.o): In function `vnc_start_tls':
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference to `gnutls_kx_set_priority'
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference to `gnutls_certificate_type_set_priority'
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'

This compilation issue can be fixed by using the new routine
gnutls_priority_set_direct() which replaces the deprecated calls
which also simplifies the code considerably.

The following Coccinelle rule expresses the change in a general
grammar form, this could be used should the code be rebased, or
to do the transformation in other projects using the same gnutls
library.

@ vars @
identifier kx_x509, kx_anon, cert_type_priority, protocol_priority;
declarer name NEED_X509_AUTH;
@@

-int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
-int kx_anon[] = { GNUTLS_KX_ANON_DH, 0};
-int kx_x509[] = { GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};

@ calls_kx_set_priority @
identifier vars.kx_x509, vars.kx_anon;
expression need_x509;
struct VncState *vs;
@@

-if (gnutls_kx_set_priority(vs->tls_session, need_x509 ? kx_x509 : kx_anon) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}

@ calls_certificate_type_set_priority depends on calls_kx_set_priority @
identifier vars.cert_type_priority;
struct VncState *calls_kx_set_priority.vs;
@@
-if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}

@ calls_protocol_set_priority depends on calls_certificate_type_set_priority @
identifier vars.protocol_priority;
struct VncState *calls_kx_set_priority.vs;
expression calls_kx_set_priority.need_x509;
@@

-if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
-	gnutls_deinit(vs->tls_session);
-	vs->tls_session = NULL;
-	vnc_client_error(vs);
-	return -1;
-}
+if (gnutls_priority_set_direct(vs->tls_session, need_x509 ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
+	gnutls_deinit(vs->tls_session);
+	vs->tls_session = NULL;
+	vnc_client_error(vs);
+	return -1;
+}

Generated-by: Coccinelle SmPL
Cc: cocci at systeme.lip6.fr
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 vnc.c | 21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

diff --git a/vnc.c b/vnc.c
index 7629dfa18645..32c604084a5b 100644
--- a/vnc.c
+++ b/vnc.c
@@ -2137,11 +2137,6 @@ static void vnc_handshake_io(void *opaque) {
 
 
 static int vnc_start_tls(struct VncState *vs) {
-    static const int cert_type_priority[] = { GNUTLS_CRT_X509, 0 };
-    static const int protocol_priority[]= { GNUTLS_TLS1_1, GNUTLS_TLS1_0, GNUTLS_SSL3, 0 };
-    static const int kx_anon[] = {GNUTLS_KX_ANON_DH, 0};
-    static const int kx_x509[] = {GNUTLS_KX_DHE_DSS, GNUTLS_KX_RSA, GNUTLS_KX_DHE_RSA, GNUTLS_KX_SRP, 0};
-
     VNC_DEBUG("Do TLS setup\n");
     if (vnc_tls_initialize() < 0) {
 	VNC_DEBUG("Failed to init TLS\n");
@@ -2161,21 +2156,7 @@ static int vnc_start_tls(struct VncState *vs) {
 	    return -1;
 	}
 
-	if (gnutls_kx_set_priority(vs->tls_session, NEED_X509_AUTH(vs) ? kx_x509 : kx_anon) < 0) {
-	    gnutls_deinit(vs->tls_session);
-	    vs->tls_session = NULL;
-	    vnc_client_error(vs);
-	    return -1;
-	}
-
-	if (gnutls_certificate_type_set_priority(vs->tls_session, cert_type_priority) < 0) {
-	    gnutls_deinit(vs->tls_session);
-	    vs->tls_session = NULL;
-	    vnc_client_error(vs);
-	    return -1;
-	}
-
-	if (gnutls_protocol_set_priority(vs->tls_session, protocol_priority) < 0) {
+	if (gnutls_priority_set_direct(vs->tls_session, NEED_X509_AUTH(vs) ? "NORMAL" : "NORMAL:+ANON-DH", NULL) < 0) {
 	    gnutls_deinit(vs->tls_session);
 	    vs->tls_session = NULL;
 	    vnc_client_error(vs);
-- 
2.6.2