xen: build fixes with gcc5 and binutils 2.25.0
cover xen: build fixes with gcc5 and binutils 2.25.0
From: "Luis R. Rodriguez" <[email protected]>
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(+)
Signature · 1 line
2.6.2
PATCH 1/9 Revert "Use the extra stack for 16bit USB and PS2 keyboard/mouse commands."
From: "Luis R. Rodriguez" <[email protected]>
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.
[0] http://lkml.kernel.org/r/[email protected]
--- src/kbd.c | 6 +++--- src/mouse.c | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
src/kbd.c +3 -3
@@ -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
src/mouse.c +3 -3
@@ -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
Signature · 1 line
2.6.2
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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;
+}
--- vnc.c | 21 +-------------------- 1 file changed, 1 insertion(+), 20 deletions(-)
vnc.c +1 -20
@@ -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);
Signature · 1 line
2.6.2
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
Using deprecate gnutls_*_set() triggers a failure to compile with gnutls30-3.4.4, used on OpenSUSE factory:
Quoted 8 lines
../libqemu_common.a(vnc.o): In function `vnc_start_tls':
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_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)
Quoted 113 lines
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 @
identifierkx_x509,kx_anon,cert_type_priority,protocol_priority; declarer nameNEED_X509_AUTH;
@@(quoted diff) +0
-4-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;
expressionneed_x509;
struct VncState *vs;
@@vnc.c +0
-6-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_prioritydepends oncalls_kx_set_priority@ identifier vars.cert_type_priority;
struct VncState *calls_kx_set_priority.vs;
@@vnc.c +0
-6-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_prioritydepends oncalls_certificate_type_set_priority@ identifier vars.protocol_priority;
struct VncState *calls_kx_set_priority.vs;
expression calls_kx_set_priority.need_x509;
@@(quoted diff) +6
-6-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 SmPLCc cocci at systeme.lip6.frSigned-off-by Luis R. Rodriguez <[email protected]>--- vnc.c | 21 +-------------------- 1 file changed, 1 insertion(+), 20 deletions(-)vnc.c +1
-20@@ -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);Signature · 7 lines
2.6.2 _______________________________________________ Xen-devel mailing list Xen-devel at lists.xen.org http://lists.xen.org/xen-devel
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 11 lines · Konrad Rzeszutek Wilk
Quoted 10 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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 tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_certificate_type_set_priority'~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
Quoted 6 lines
Quoted 3 lines
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?
Quoted 19 lines
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_credentialsanon_cred=
Quoted 5 lines
vnc_tls_initialize_anon_cred(); ^?
(This is Fedora 23)
Nope.
Luis
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 12 lines · Luis R. Rodriguez
Quoted 11 lines · Konrad Rzeszutek Wilk
Quoted 10 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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 tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_certificate_type_set_priority'~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2178: undefined reference to `gnutls_protocol_set_priority'
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
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?
Quoted 29 lines
Quoted 20 lines
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_credentialsanon_cred=Quoted 5 lines
vnc_tls_initialize_anon_cred(); ^?
(This is Fedora 23)
Nope.
Luis
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 18 lines · Konrad Rzeszutek Wilk
Quoted 17 lines · Luis R. Rodriguez
Quoted 16 lines · Konrad Rzeszutek Wilk
Quoted 13 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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 tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_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.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Thanks for posting that! It certainly fixes that issue.
Acked-by?
None of these are merged yet...
Luis
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 19 lines · Luis R. Rodriguez
Quoted 18 lines · Konrad Rzeszutek Wilk
Quoted 17 lines · Luis R. Rodriguez
Quoted 16 lines · Konrad Rzeszutek Wilk
Quoted 13 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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 tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Thanks for posting that! It certainly fixes that issue.
Acked-by?
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?
Quoted 2 lines
Luis
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 22 lines · Konrad Rzeszutek Wilk
Quoted 21 lines · Luis R. Rodriguez
Quoted 20 lines · Konrad Rzeszutek Wilk
Quoted 19 lines · Luis R. Rodriguez
Quoted 17 lines · Konrad Rzeszutek Wilk
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
Using deprecate gnutls_*_set() triggers a failure to compile with gnutls30-3.4.4, used on OpenSUSE factory:
Quoted 8 lines
../libqemu_common.a(vnc.o): In function `vnc_start_tls':
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Acked-by?
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 <[email protected]>
Ian Jackson <[email protected]>
Jan Beulich <[email protected]>
Keir Fraser <[email protected]>
Tim Deegan <[email protected]>
xen-devel at lists.xen.org
I missed Ian Jackson, Keir and Tim.
Quoted 2 lines
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
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 6 lines
Quoted 2 lines
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.
Quoted 2 lines
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?)
Quoted 2 lines
Luis
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 6 lines · Konrad Rzeszutek Wilk
Quoted 2 lines
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
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
In reply to Luis R. RodriguezQuoted 44 lines · Luis R. Rodriguez
Quoted 22 lines · Konrad Rzeszutek Wilk
Quoted 21 lines · Luis R. Rodriguez
Quoted 20 lines · Konrad Rzeszutek Wilk
Quoted 19 lines · Luis R. Rodriguez
Quoted 17 lines · Konrad Rzeszutek Wilk
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
Using deprecate gnutls_*_set() triggers a failure to compile with gnutls30-3.4.4, used on OpenSUSE factory:
Quoted 8 lines
../libqemu_common.a(vnc.o): In function `vnc_start_tls':
~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2164: undefined reference tognutls_kx_set_priority' ~/devel/xen/tools/qemu-xen-traditional-dir/vnc.c:2171: undefined reference tognutls_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.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Acked-by?
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.patchIan Campbell <[email protected]>
Ian Jackson <[email protected]>
Jan Beulich <[email protected]>
Keir Fraser <[email protected]>
Tim Deegan <[email protected]>
xen-devel at lists.xen.orgI missed Ian Jackson, Keir and Tim.
Quoted 2 lines
Also - how does this work if you have an older version of SuSE, say SLES10?
Quoted 8 lines
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
Signature · 9 lines
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()
In reply to Luis R. RodriguezQuoted 10 lines
Quoted 1 line
Quoted 1 line · On 06.02.16 at 05:03, <[email protected]> wrote:
Quoted 2 lines · 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 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
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 11 lines · Jan Beulich
Quoted 10 lines
Quoted 1 line
Quoted 1 line · On 06.02.16 at 05:03, <[email protected]> wrote:
Quoted 2 lines · 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 library could just add a helper
gnutls_priority_set_direct()wrapper to do things the old way.
Quoted 6 lines
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 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 20 lines
Quoted 1 line
Quoted 1 line · On 09.02.16 at 16:46, <[email protected]> wrote:
Quoted 11 lines · Jan Beulich
Quoted 10 lines
Quoted 1 line
Quoted 1 line · On 06.02.16 at 05:03, <[email protected]> wrote:
Quoted 2 lines · 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 library could just add a helper
gnutls_priority_set_direct()wrapper to do things the old way.Quoted 6 lines
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).
Quoted 6 lines
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 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
In reply to Konrad Rzeszutek WilkQuoted 2 lines · Konrad Rzeszutek Wilk
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
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 5 lines · Olaf Hering
Quoted 2 lines · Konrad Rzeszutek Wilk
Also - how does this work if you have an older version of SuSE, say SLES10?
Quoted 7 lines
SLE10 is out of scope since along time already. This patch for current gnutls is already in qemu mainline.
f40d55081667a716312b9a8b6e13835c4074f56b7d2a929feba319c18603e324b1750830d6c8b7a1I 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 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 2 lines · Luis R. Rodriguez
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
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 6 lines · Olaf Hering
Quoted 2 lines · Luis R. Rodriguez
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: [PATCH 2/9] Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 32 lines · Luis R. Rodriguez
Quoted 6 lines · Olaf Hering
Quoted 2 lines · Luis R. Rodriguez
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~325mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
7d2a929feba319c18603e324b1750830d6c8b7a1v1.5.0-rc0~660mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
d321e1e526810
v2.5.0-rc0~125^2~2As for the other fix I backported for the existing release carried:
mcgrof@ergon ~/devel/qemu (git::master)$ git describe --contains
98d23704138e0be17a3ed9eb2631077bf92cc028
v1.1-rc0~785I 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 ?
Quoted 5 lines
mcgrof@ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote (git::dummy)$ cat VERSION
0.10.2If 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.
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 54 lines · Ian Campbell
Quoted 32 lines · Luis R. Rodriguez
Quoted 6 lines · Olaf Hering
Quoted 2 lines · Luis R. Rodriguez
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~325mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
7d2a929feba319c18603e324b1750830d6c8b7a1
v1.5.0-rc0~660mcgrof at ergon ~/devel/qemu (git::master)$ git describe --contains
d321e1e526810
v2.5.0-rc0~125^2~2As 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~785I 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 ?
Quoted 5 lines
mcgrof at ergon ~/devel/xen/tools/qemu-xen-traditional-dir-remote (git::dummy)$ cat VERSION
0.10.2If 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:
Quoted 7 lines
./configure --disable-qemu-traditionaland 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()
Quoted 2 lines · Luis R. Rodriguez
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
PATCH 2/9 Use gnutls_priority_set_direct() to deprecate gnutls_*_set()
Quoted 6 lines · Olaf Hering
Quoted 2 lines · Luis R. Rodriguez
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
PATCH 3/9 hw/usb-net.c: fix state check
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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 <[email protected]> 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.
--- hw/usb-net.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
hw/usb-net.c +2 -2
@@ -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;
Signature · 1 line
2.6.2
PATCH 4/9 qemu-xen-dir: spice: remove spice-experimental.h include
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
Upstream qemu commit e0883e2de0ef36f254acc274e80ddeac13a2a8f6 ("spice: remove spice-experimental.h include")
commit e0883e2de0ef36f254acc274e80ddeac13a2a8f6
Author: Marc-André Lureau <[email protected]> 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.
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
--- spice-qemu-char.c | 1 - ui/spice-core.c | 1 - 2 files changed, 2 deletions(-)
spice-qemu-char.c +0 -1
@@ -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"
ui/spice-core.c +0 -1
@@ -16,7 +16,6 @@*/ #include <spice.h> -#include <spice-experimental.h> #include <netdb.h> #include "sysemu/sysemu.h"
Signature · 7 lines
2.6.2 _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
PATCH 5/9 qemu-xen-dir: virtio-rng: fix check for period_ms validity
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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 <[email protected]>
Cc: Gonglei <[email protected]>
Amos Kong <[email protected]>
--- hw/virtio/virtio-rng.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
hw/virtio/virtio-rng.c +1 -1
@@ -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 ; }
Signature · 7 lines
2.6.2 _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
PATCH 6/9 mini-os: fix linker warning with app.lds
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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?
--- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Makefile +1 -1
@@ -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
Signature · 1 line
2.6.2
PATCH 7/9 stubdom: fix unfound libgmp library issues
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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
--- stubdom/Makefile | 5 +++++ 1 file changed, 5 insertions(+)
stubdom/Makefile +5 -0
@@ -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)
Signature · 1 line
2.6.2
PATCH 8/9 vtpm: fix vtpmblk.c compilation warning
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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
--- stubdom/vtpm/vtpmblk.c | 1 + 1 file changed, 1 insertion(+)
stubdom/vtpm/vtpmblk.c +1 -0
@@ -18,6 +18,7 @@#include "polarssl/sha1.h" #include <blkfront.h> #include <unistd.h> +#include <stdio.h> #include <errno.h> #include <fcntl.h>
Signature · 7 lines
2.6.2 _______________________________________________ Xen-devel mailing list [email protected] http://lists.xen.org/xen-devel
PATCH 9/9 vtpm: guard against redefining TPM_VENDOR_COMMAND
In reply to Luis R. RodriguezFrom: "Luis R. Rodriguez" <[email protected]>
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
--- stubdom/vtpmmgr/vtpm_manager.h | 3 +++ 1 file changed, 3 insertions(+)
stubdom/vtpmmgr/vtpm_manager.h +3 -0
@@ -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)/*
Signature · 1 line
2.6.2
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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 <[email protected]> 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
Quoted 9 lines · Luis R. Rodriguez
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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'.
Quoted 9 lines
Patches for fixes on builds last ages to get merged
In this case Mark Pryor <[email protected]> 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.
Quoted 4 lines
***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.
Quoted 4 lines
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.
Quoted 4 lines
[0] http://comments.gmane.org/gmane.comp.emulators.xen.devel/264183
Luis
Quoted 9 lines · Konrad Rzeszutek Wilk
Quoted 8 lines · Luis R. Rodriguez
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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.
Quoted 6 lines
Quoted 1 line
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.
Quoted 8 lines
Quoted 8 lines
Patches for fixes on builds last ages to get merged
In this case Mark Pryor <[email protected]> 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.
Quoted 7 lines
Quoted 4 lines
***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.
Quoted 3 lines
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.
Quoted 5 lines
Quoted 3 lines
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
Quoted 33 lines · Luis R. Rodriguez
Quoted 9 lines · Konrad Rzeszutek Wilk
Quoted 8 lines · Luis R. Rodriguez
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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.
Quoted 6 lines
Quoted 1 line
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.
Quoted 13 lines
Quoted 12 lines
Patches for fixes on builds last ages to get merged
In this case Mark Pryor <[email protected]> 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...
Quoted 5 lines
Quoted 2 lines
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.
Quoted 19 lines
Quoted 4 lines
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.
Quoted 5 lines
Quoted 3 lines
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.
Quoted 4 lines
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/
Signature · 1 line
Doug Goldstein
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel
Hi Doug,
Quoted 5 lines
Quoted 5 lines
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.
Quoted 8 lines
Quoted 4 lines
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]?
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
Quoted 2 lines · Luis R. Rodriguez
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.
Quoted 6 lines
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
[email protected]
http://lists.xen.org/xen-devel
Quoted 6 lines · Ian Campbell
Quoted 2 lines · Luis R. Rodriguez
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.
Quoted 4 lines
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.
Quoted 4 lines
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/x86anddrivers/netfixes to Linus+GregKH and have anything useful happen to them.
That's right.
Quoted 5 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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
MAINTAINERSfile 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
Quoted 4 lines · Luis R. Rodriguez
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.
Quoted 3 lines
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.
Quoted 7 lines
Quoted 4 lines
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).
Quoted 10 lines
Quoted 6 lines
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.gitMAINTAINERSfile lists
the right people.Sure, I do both though, first real upstream and then prod the Xen maintainers. I take it
scripts/get_maintainer.plshould 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
[email protected]
http://lists.xen.org/xen-devel
Quoted 8 lines · Ian Campbell
Quoted 4 lines · Luis R. Rodriguez
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
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.gitMAINTAINERSfile lists
the right people.
Quoted 6 lines
Quoted 3 lines
Sure, I do both though, first real upstream and then prod the Xen maintainers. I take it
scripts/get_maintainer.plshould work though? I tried it in a few patches and it seemed to have workedI 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
Quoted 15 lines · Luis R. Rodriguez
Quoted 3 lines
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
Quoted 2 lines
Since I can't seem to rely on
scripts/get_maintainer.plI 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.
Quoted 11 lines
Quoted 1 line
Quoted 1 line · On 06.02.16 at 02:48, <[email protected]> wrote:
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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:
Quoted 7 lines
Patches for fixes on builds last ages to get merged
In this case Mark Pryor <[email protected]> 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.
Quoted 8 lines
***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
Quoted 27 lines · Jan Beulich
Quoted 11 lines
Quoted 1 line
Quoted 1 line · On 06.02.16 at 02:48, <[email protected]> wrote:
Quoted 5 lines · Luis R. Rodriguez
From: "Luis R. Rodriguez" <[email protected]>
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:
Quoted 7 lines
Patches for fixes on builds last ages to get merged
In this case Mark Pryor <[email protected]> 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.
Quoted 5 lines
***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...
Quoted 6 lines
Quoted 3 lines
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.
Quoted 3 lines
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 <[email protected]> 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 <[email protected]> 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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 2 lines
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
Quoted 3 lines · Luis R. Rodriguez
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
[email protected]
http://lists.xen.org/xen-devel
Quoted 7 lines · Ian Campbell
Quoted 3 lines · Luis R. Rodriguez
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;
Quoted 3 lines
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
[email protected]
http://lists.xen.org/xen-devel
Quoted 9 lines · Luis R. Rodriguez
Quoted 7 lines · Ian Campbell
Quoted 3 lines · Luis R. Rodriguez
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
Quoted 6 lines
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.
Quoted 7 lines
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:
Quoted 8 lines
=== 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’ typedefxen_sysctl_topologyinfo_txc_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
[email protected]
http://lists.xen.org/xen-devel
Quoted 10 lines · Ian Campbell
Quoted 9 lines · Luis R. Rodriguez
Quoted 7 lines · Ian Campbell
Quoted 3 lines · Luis R. Rodriguez
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
Quoted 8 lines
Quoted 6 lines
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 directoryMissing 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.
Quoted 16 lines
Quoted 7 lines
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:
Quoted 8 lines
=== 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’ typedefxen_sysctl_topologyinfo_txc_topologyinfo_t;
Quoted 3 lines
If this was building from xen.git then the problem would appear to be that it is picking up headers from
/usr/localinstead 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.
Quoted 2 lines
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
[email protected]
http://lists.xen.org/xen-devel
Quoted 6 lines · Luis R. Rodriguez
Quoted 1 line
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-dirif no such sdl dev packages is found.
Quoted 8 lines
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
Quoted 14 lines · Luis R. Rodriguez
Quoted 10 lines
Quoted 9 lines
=== 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’ typedefxen_sysctl_topologyinfo_txc_topologyinfo_t;Quoted 3 lines
If this was building from xen.git then the problem would appear to be that it is picking up headers from
/usr/localinstead of the ones from in tree (i.e. the libraries its just built).
Quoted 5 lines
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:
Quoted 2 lines
Quoted 2 lines
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
[email protected]
http://lists.xen.org/xen-devel
Quoted 11 lines · Ian Campbell
Quoted 10 lines
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’
typedefxen_sysctl_topologyinfo_txc_topologyinfo_t;
Quoted 3 lines
If this was building from xen.git then the problem would appear to be that it is picking up headers from
/usr/localinstead 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
[email protected]
http://lists.xen.org/xen-devel
Quoted 2 lines · Luis R. Rodriguez
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.
Quoted 2 lines · Luis R. Rodriguez
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
Quoted 5 lines · Ian Campbell
Quoted 3 lines · Luis R. Rodriguez
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.
Quoted 7 lines
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
Signature · 4 lines
<<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)
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xen.org/xen-devel