[Spice-devel] [PATCH] Free coroutine stack when releasing coroutine
From: Daniel P. Berrange berra...@redhat.com The coroutine_init function mmap's a stack for the ucontext coroutine, but nothing ever munmaps it. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- gtk/coroutine_ucontext.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gtk/coroutine_ucontext.c b/gtk/coroutine_ucontext.c index 79e4afe..f65337e 100644 --- a/gtk/coroutine_ucontext.c +++ b/gtk/coroutine_ucontext.c @@ -48,6 +48,8 @@ static int _coroutine_release(struct continuation *cc) return ret; } + munmap(co-cc.stack, co-cc.stack_size); + co-caller = NULL; return 0; -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Free coroutine stack when releasing coroutine
ack - Original Message - From: Daniel P. Berrange berra...@redhat.com The coroutine_init function mmap's a stack for the ucontext coroutine, but nothing ever munmaps it. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- gtk/coroutine_ucontext.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gtk/coroutine_ucontext.c b/gtk/coroutine_ucontext.c index 79e4afe..f65337e 100644 --- a/gtk/coroutine_ucontext.c +++ b/gtk/coroutine_ucontext.c @@ -48,6 +48,8 @@ static int _coroutine_release(struct continuation *cc) return ret; } + munmap(co-cc.stack, co-cc.stack_size); + co-caller = NULL; return 0; -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [PATCH] Abort if mmap of coroutine stack fails
From: Daniel P. Berrange berra...@redhat.com If we fail to mmap the stack, abort the processs rather than returning an error. This is standard practice in glib apps, and the caller was not checking the coroutine_init() return code leading to memory corruption. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- gtk/coroutine_ucontext.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gtk/coroutine_ucontext.c b/gtk/coroutine_ucontext.c index af811a7..79e4afe 100644 --- a/gtk/coroutine_ucontext.c +++ b/gtk/coroutine_ucontext.c @@ -20,6 +20,7 @@ #include config.h +#include glib.h #ifdef HAVE_SYS_TYPES_H #include sys/types.h #endif @@ -69,7 +70,8 @@ int coroutine_init(struct coroutine *co) MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (co-cc.stack == MAP_FAILED) - return -1; + g_error(Failed to allocate %u bytes for coroutine stack, + (unsigned)co-stack_size); co-cc.entry = coroutine_trampoline; co-cc.release = _coroutine_release; co-exited = 0; -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] [PATCH] Abort if mmap of coroutine stack fails
ack - Original Message - From: Daniel P. Berrange berra...@redhat.com If we fail to mmap the stack, abort the processs rather than returning an error. This is standard practice in glib apps, and the caller was not checking the coroutine_init() return code leading to memory corruption. Signed-off-by: Daniel P. Berrange berra...@redhat.com --- gtk/coroutine_ucontext.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/gtk/coroutine_ucontext.c b/gtk/coroutine_ucontext.c index af811a7..79e4afe 100644 --- a/gtk/coroutine_ucontext.c +++ b/gtk/coroutine_ucontext.c @@ -20,6 +20,7 @@ #include config.h +#include glib.h #ifdef HAVE_SYS_TYPES_H #include sys/types.h #endif @@ -69,7 +70,8 @@ int coroutine_init(struct coroutine *co) MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); if (co-cc.stack == MAP_FAILED) - return -1; + g_error(Failed to allocate %u bytes for coroutine stack, + (unsigned)co-stack_size); co-cc.entry = coroutine_trampoline; co-cc.release = _coroutine_release; co-exited = 0; -- 1.8.3.1 ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] wireshark codegen
Opinions on this? The end goal is to be able to generate a header that has
both the enums and descriptions of those enum values (e.g. a mapping from enum
to string name) that we can use for the wireshark dissector. Obviously, when a
new channel or new message gets added to the protocol, there is still some
manual work that needs to be done to update the wireshark dissector, but being
able to autogenerate theses values reduces the maintenance burden for this part
at least.
From c6cef8747b61e203ebb8ade580dae063d581afb2 Mon Sep 17 00:00:00 2001
From: Jonathon Jongsma jjong...@redhat.com
Date: Thu, 12 Sep 2013 12:11:02 -0500
Subject: [PATCH] codegen: Add a --generate-wireshark-dissector option
The wireshark protocol dissector is a bit out-of-date. Several new channel types
and enums have been added. It would be nice if these values (and the
translation between the value and the name) could be automatically generated so
that updating the dissector was a slightly less manual process. This patch adds
a commandline switch which generates both the enums and value-name lists in the
format that wireshark expects.
---
python_modules/codegen.py | 2 +-
python_modules/ptypes.py | 17
spice_codegen.py | 105 ++
3 files changed, 87 insertions(+), 37 deletions(-)
diff --git a/python_modules/codegen.py b/python_modules/codegen.py
index 009cf95..5dee0b8 100644
--- a/python_modules/codegen.py
+++ b/python_modules/codegen.py
@@ -41,7 +41,7 @@ def set_prefix(prefix):
def prefix_underscore_upper(*args):
s = proto_prefix_upper
for arg in args:
-s = s + _ + arg
+s = s + _ + arg.upper()
return s
def prefix_underscore_lower(*args):
diff --git a/python_modules/ptypes.py b/python_modules/ptypes.py
index d9fbfe2..2bfbf0d 100644
--- a/python_modules/ptypes.py
+++ b/python_modules/ptypes.py
@@ -247,6 +247,23 @@ class EnumBaseType(Type):
def get_fixed_nw_size(self):
return self.bits / 8
+# generates a value-name table suitable for use with the wireshark protocol
+# dissector
+def c_describe(self, writer):
+writer.write(static const value_string %s_vs[] = %
codegen.prefix_underscore_lower(self.name))
+writer.begin_block()
+values = self.names.keys()
+values.sort()
+for i in values:
+writer.write({ )
+writer.write(self.c_enumname(i))
+writer.write(, \%s\ }, % self.names[i])
+writer.newline()
+writer.write({ 0, NULL })
+writer.end_block(semicolon=True)
+writer.newline()
+
+
class EnumType(EnumBaseType):
def __init__(self, bits, name, enums, attribute_list):
Type.__init__(self)
diff --git a/spice_codegen.py b/spice_codegen.py
index e9e64c0..de1f87b 100755
--- a/spice_codegen.py
+++ b/spice_codegen.py
@@ -10,38 +10,73 @@ from python_modules import codegen
from python_modules import demarshal
from python_modules import marshal
-def write_channel_enums(writer, channel, client):
+def write_channel_enums(writer, channel, client, describe):
messages = filter(lambda m : m.channel == channel, \
channel.client_messages if client else
channel.server_messages)
if len(messages) == 0:
return
-writer.begin_block(enum)
-i = 0
if client:
-prefix = [ MSGC ]
+prefix = [ msgc ]
else:
-prefix = [ MSG ]
+prefix = [ msg ]
if channel.member_name:
-prefix.append(channel.member_name.upper())
+prefix.append(channel.member_name)
+if not describe:
+writer.begin_block(enum)
+else:
+writer.begin_block(static const value_string %s_vs[] = %
(codegen.prefix_underscore_lower(*prefix)))
+i = 0
prefix.append(None) # To be replaced with name
for m in messages:
-prefix[-1] = m.name.upper()
+prefix[-1] = m.name
enum = codegen.prefix_underscore_upper(*prefix)
-if m.value == i:
-writer.writeln(%s, % enum)
-i = i + 1
+if describe:
+writer.writeln({ %s, \%s %s\ }, % (enum, Client if client
else Server, m.name.upper()))
else:
-writer.writeln(%s = %s, % (enum, m.value))
-i = m.value + 1
-if channel.member_name:
-prefix[-1] = prefix[-2]
-prefix[-2] = END
-writer.newline()
-writer.writeln(%s % (codegen.prefix_underscore_upper(*prefix)))
+if m.value == i:
+writer.writeln(%s, % enum)
+i = i + 1
+else:
+writer.writeln(%s = %s, % (enum, m.value))
+i = m.value + 1
+if describe:
+writer.writeln({ 0, NULL });
+else:
+if channel.member_name:
+prefix[-1] = prefix[-2]
+prefix[-2] = END
+writer.newline()
+writer.writeln(%s % (codegen.prefix_underscore_upper(*prefix)))
[Spice-devel] [spice-html5] Give the Garbage collector a clue to recycle images; avoids fairly massive memory leaks during video playback.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
display.js |4
1 file changed, 4 insertions(+)
diff --git a/display.js b/display.js
index f9bfe76..d0d0994 100644
--- a/display.js
+++ b/display.js
@@ -778,6 +778,10 @@ function handle_draw_jpeg_onload()
{
context.drawImage(this, this.o.base.box.left, this.o.base.box.top);
+// Give the Garbage collector a clue to recycle this; avoids
+// fairly massive memory leaks during video playback
+this.src = null;
+
if (this.o.descriptor
(this.o.descriptor.flags SPICE_IMAGE_FLAGS_CACHE_ME))
{
--
1.7.10.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] oVirt support in aSPICE stalled due to broken network file I/O
Hi Christophe, I read through some govirt code, and I think you're right that gvfs is only used during the fetching of the certificate. If that's the case, I will start by not fetching the CA automatically, but requiring for users to provide it to aSPICE the same way as they have to provide it for a simple SPICE connection (within the Import CA dialog in aSPICE, which is analogous to the --spice-ca-file option in virt-viewer). I think this will work for most if not all people. Thanks again! iordan On Thu, Sep 12, 2013 at 1:20 PM, Christophe Fergeau cferg...@redhat.comwrote: Hey Iordan, On Thu, Sep 12, 2013 at 01:11:45PM -0400, i iordanov wrote: Hi Christophe, It is currently very hard, bordering on impossible to build gvfs for Android, because it ends up depending on GTK. The sequence of dependencies is: glib network I/O - gvfs - libsoup-gnome - gnome-keyring - gcr-3 - gcr-ui-3 - GTK The glib guys are arguing that this is not a bug, since it's just a dependency that's missing, but I am trying to convince them that the low-level glib should not end up depending on a UI library... Hence for the moment, I absolutely cannot use glib network I/O. Can you tell me, since you've written libgovirt, do you think it's possible to add functionality to *it* rather than writing workarounds for client software? I could work around this issue in aSPICE, but that would not help for any other client on any other platform that doesn't have GTK. Regardless of whether you do agree it's best if govirt either stopped relying on glib network file I/O or had an option to use a different method, what library would you say would be best suited to replace all the network file I/O operations that you have in govirt with a download - local file I/O sequence? Libcurl comes to mind, but perhaps libsoup is better suited for the purpose in your opinion? Could you try what I suggested in http://lists.freedesktop.org/archives/spice-devel/2013-September/014430.html ? I think gvfs is only used if you use the helpers to fetch the certificate, and the rest of the code is just doing calls into librest/libsoup which I think are not using gio/gvfs. If this is a correct, then I think it's not a big issue that you don't have gvfs on your platform. If it is, I'll have to look where/how it's used to figure out how to workaround this. Hope that helps, Christophe -- The conscious mind has only one thread of execution. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] More on virt-viewer for windows
Hi there, As the newer windows binaries kindly provided by teuf won't work because of missing DLLs, I returned to the latest binaries provided by spice-space.org. remove-viewer.exe works fine, after I foud where to put TLS certificates. Not that user-friendly though. :-) virt-viewer and virsh won't connect, although they are using the same certificates as a Linux client. The short-term goal is getting virt-manager to work, butI think it'd be easier to get virsh working first, but the solution would apply to virt-manager as well. Microsoft SystemInternals ProccessMonitor shows the certificates are being found and read (that's how I found where to put then). I assume that's ok. But after that nothing I can use for troubleshooting. Looks like a bug on the windows port networking code. But I finally found how to use libvirt own debugging features. So here's attached a log for the windows machine, which can't connect, and the linux machine, which connects fine to the same kvm host, using the same certificates and the same URL (to the same CentOS 6.3 kvm host). They are using different virsh and libvirt releases, so I added to the logs the output of virsh -V. Both machines are on the same level-2 network, vlan and IP subnet. I hope this helps someone find the bug and provide me with new binaries to test. :-) If someone helps me getting the missing DLLs for teuf newer binaries, I can generate a log using them. It looks the missing DLLs is another bug per se. Of course, I hope someonte at Red Hat realizes a missing or broken windows ports hurts KVM and RHEL and RHEV market share and put more people on it. :-) PS: Someone offered helping me compiling the windows port. I'll give it a try, no promises, free time is very scarse. :-( []s, Fernando Lozano ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] oVirt support in aSPICE stalled due to broken network file I/O
Hi Christophe, I hope this is not too much to ask, but would it be possible for OvirtProxy to have a ca-cert-file property as well as a ca-cert property? This way, supporting the spice-ca-file option as well as the existing aSPICE functionality will be much easier. Thanks! iordan On Fri, Sep 13, 2013 at 12:09 PM, i iordanov iiorda...@gmail.com wrote: Hi Christophe, I read through some govirt code, and I think you're right that gvfs is only used during the fetching of the certificate. If that's the case, I will start by not fetching the CA automatically, but requiring for users to provide it to aSPICE the same way as they have to provide it for a simple SPICE connection (within the Import CA dialog in aSPICE, which is analogous to the --spice-ca-file option in virt-viewer). I think this will work for most if not all people. Thanks again! iordan On Thu, Sep 12, 2013 at 1:20 PM, Christophe Fergeau cferg...@redhat.comwrote: Hey Iordan, On Thu, Sep 12, 2013 at 01:11:45PM -0400, i iordanov wrote: Hi Christophe, It is currently very hard, bordering on impossible to build gvfs for Android, because it ends up depending on GTK. The sequence of dependencies is: glib network I/O - gvfs - libsoup-gnome - gnome-keyring - gcr-3 - gcr-ui-3 - GTK The glib guys are arguing that this is not a bug, since it's just a dependency that's missing, but I am trying to convince them that the low-level glib should not end up depending on a UI library... Hence for the moment, I absolutely cannot use glib network I/O. Can you tell me, since you've written libgovirt, do you think it's possible to add functionality to *it* rather than writing workarounds for client software? I could work around this issue in aSPICE, but that would not help for any other client on any other platform that doesn't have GTK. Regardless of whether you do agree it's best if govirt either stopped relying on glib network file I/O or had an option to use a different method, what library would you say would be best suited to replace all the network file I/O operations that you have in govirt with a download - local file I/O sequence? Libcurl comes to mind, but perhaps libsoup is better suited for the purpose in your opinion? Could you try what I suggested in http://lists.freedesktop.org/archives/spice-devel/2013-September/014430.html ? I think gvfs is only used if you use the helpers to fetch the certificate, and the rest of the code is just doing calls into librest/libsoup which I think are not using gio/gvfs. If this is a correct, then I think it's not a big issue that you don't have gvfs on your platform. If it is, I'll have to look where/how it's used to figure out how to workaround this. Hope that helps, Christophe -- The conscious mind has only one thread of execution. -- The conscious mind has only one thread of execution. ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] vdagent protocol question
The clipboard message currently include an optional 4bytes enty for 'selection':
typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
uint32_t types[0];
} VDAgentClipboardGrab;
This makes it really hard to write nice code.
I wonder why it does not simply use the 'opaque' field of VDAgentMessage
instead?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] vdagent protocol question
This makes it really hard to write nice code. I don't think I would have done it if it was really hard. But I understand in your code it might be difficult for some reason. It is not 'really' hard (but a bit 'ugly') I wonder why it does not simply use the ‘opaque’ field of VDAgentMessage instead? I have No idea what this opaque is for, but I prefer the information to be explicit. I just read this: http://spice-space.org/page/Whiteboard/AgentProtocol According to that, this field is exactly for that use case. What if you consider it as a different message with a different structure somehow? Why don't you simply always include those bytes instead? ___ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] vdagent protocol question
Hi
- Original Message -
The clipboard message currently include an optional 4bytes enty for
‘selection’:
typedef struct SPICE_ATTR_PACKED VDAgentClipboardGrab {
#if 0 /* VD_AGENT_CAP_CLIPBOARD_SELECTION */
uint8_t selection;
uint8_t __reserved[sizeof(uint32_t) - 1 * sizeof(uint8_t)];
#endif
uint32_t types[0];
} VDAgentClipboardGrab;
This makes it really hard to write nice code.
I don't think I would have done it if it was really hard. But I understand in
your code it might be difficult for some reason.
I wonder why it does not simply use the ‘opaque’ field of VDAgentMessage
instead?
I have No idea what this opaque is for, but I prefer the information to be
explicit.
What if you consider it as a different message with a different structure
somehow?
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [xf86-video-qxl] Provide compatibility for Xorg list code with Xorg 1.12, for RHEL 6 support (resend)
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
src/qxl.h | 12 +++-
src/qxl_kms.c |2 +-
src/qxl_mem.c |2 +-
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/qxl.h b/src/qxl.h
index c026b63..a3bc7db 100644
--- a/src/qxl.h
+++ b/src/qxl.h
@@ -56,6 +56,16 @@
#include qxl_drmmode.h
+#if (XORG_VERSION_CURRENT XORG_VERSION_NUMERIC(1, 11, 99, 903, 0))
+typedef struct list xorg_list_t;
+#define xorg_list_init list_init
+#define xorg_list_add list_add
+#define xorg_list_del list_del
+#define xorg_list_for_each_entrylist_for_each_entry
+#else
+typedef struct xorg_list xorg_list_t;
+#endif
+
#include compat-api.h
#define hidden _X_HIDDEN
@@ -332,7 +342,7 @@ struct _qxl_screen_t
#endif /* XSPICE */
uint32_t deferred_fps;
-struct xorg_list ums_bos;
+xorg_list_t ums_bos;
struct qxl_bo_funcs *bo_funcs;
Bool kms_enabled;
diff --git a/src/qxl_kms.c b/src/qxl_kms.c
index 32859cc..6c5b427 100644
--- a/src/qxl_kms.c
+++ b/src/qxl_kms.c
@@ -338,7 +338,7 @@ struct qxl_kms_bo {
const char *name;
uint32_t size;
int type;
-struct xorg_list bos;
+xorg_list_t bos;
void *mapping;
qxl_screen_t *qxl;
int refcnt;
diff --git a/src/qxl_mem.c b/src/qxl_mem.c
index 44be8c4..fde0976 100644
--- a/src/qxl_mem.c
+++ b/src/qxl_mem.c
@@ -448,7 +448,7 @@ struct qxl_ums_bo {
void *internal_virt_addr;
int refcnt;
qxl_screen_t *qxl;
-struct xorg_list bos;
+xorg_list_t bos;
};
static struct qxl_bo *qxl_bo_alloc_internal(qxl_screen_t *qxl, int type, int
flags, unsigned long size, const char *name)
--
1.7.10.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
[Spice-devel] [spice-html5] Send the client cache size correctly in little endian order so we don't claim to have an infinitely large cache.
Signed-off-by: Jeremy White jwh...@codeweavers.com
---
spicedataview.js | 12
spicemsg.js |3 +--
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/spicedataview.js b/spicedataview.js
index ef9555d..43f0170 100644
--- a/spicedataview.js
+++ b/spicedataview.js
@@ -93,4 +93,16 @@ SpiceDataView.prototype = {
this.setUint16(byteOffset + high, (w 0x) 16,
littleEndian);
this.setUint16(byteOffset + low, (w 0x), littleEndian);
},
+setUint64: function(byteOffset, w, littleEndian)
+{
+var low = 4, high = 0;
+if (littleEndian)
+{
+low = 0;
+high = 4;
+}
+
+this.setUint32(byteOffset + high, (w 0x) 32,
littleEndian);
+this.setUint32(byteOffset + low, (w 0x),
littleEndian);
+},
}
diff --git a/spicemsg.js b/spicemsg.js
index 365fdf7..e342d6a 100644
--- a/spicemsg.js
+++ b/spicemsg.js
@@ -445,8 +445,7 @@ SpiceMsgcDisplayInit.prototype =
at = at || 0;
var dv = new SpiceDataView(a);
dv.setUint8(at, this.pixmap_cache_id, true); at++;
-dv.setUint32(at, 0, true); at += 4;
-dv.setUint32(at, this.pixmap_cache_size, true); at += 4;
+dv.setUint64(at, this.pixmap_cache_size, true); at += 8;
dv.setUint8(at, this.glz_dictionary_id, true); at++;
dv.setUint32(at, this.glz_dictionary_window_size, true); at += 4;
},
--
1.7.10.4
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
Re: [Spice-devel] oVirt support in aSPICE stalled due to broken network file I/O
Hi Christophe,
If adding a ca-file property to OvirtProxy is not acceptable, would you
consider adding (something like) the following function to ovirt-proxy.c?
Please note that this is a preliminary variant that I haven't tested much,
and may not have enough error checking!
void ovirt_proxy_load_ca_cert_file (OvirtProxy *proxy,
const gchar *ca_file_name,
GError **error)
{
GMappedFile *ca_file = NULL;
GBytes *bytes = NULL;
gconstpointer ca_data;
gsize cert_length = 0;
ca_file = g_mapped_file_new(ca_file_name, FALSE, error);
if (ca_file == NULL) {
goto error;
}
bytes = g_mapped_file_get_bytes(ca_file);
cert_length = g_bytes_get_size(bytes);
ca_data = g_bytes_get_data (bytes, cert_length);
set_downloaded_ca_cert(proxy, (char*)ca_data, cert_length);
error:
if (ca_file != NULL)
g_object_unref(ca_file);
if (bytes != NULL)
g_object_unref(bytes);
}
Cheers,
iordan
On Fri, Sep 13, 2013 at 12:53 PM, i iordanov iiorda...@gmail.com wrote:
Hi Christophe,
I hope this is not too much to ask, but would it be possible for
OvirtProxy to have a ca-cert-file property as well as a ca-cert property?
This way, supporting the spice-ca-file option as well as the existing
aSPICE functionality will be much easier.
Thanks!
iordan
On Fri, Sep 13, 2013 at 12:09 PM, i iordanov iiorda...@gmail.com wrote:
Hi Christophe,
I read through some govirt code, and I think you're right that gvfs is
only used during the fetching of the certificate. If that's the case, I
will start by not fetching the CA automatically, but requiring for users to
provide it to aSPICE the same way as they have to provide it for a simple
SPICE connection (within the Import CA dialog in aSPICE, which is
analogous to the --spice-ca-file option in virt-viewer). I think this will
work for most if not all people.
Thanks again!
iordan
On Thu, Sep 12, 2013 at 1:20 PM, Christophe Fergeau
cferg...@redhat.comwrote:
Hey Iordan,
On Thu, Sep 12, 2013 at 01:11:45PM -0400, i iordanov wrote:
Hi Christophe,
It is currently very hard, bordering on impossible to build gvfs for
Android, because it ends up depending on GTK. The sequence of
dependencies is:
glib network I/O - gvfs - libsoup-gnome - gnome-keyring - gcr-3 -
gcr-ui-3 - GTK
The glib guys are arguing that this is not a bug, since it's just a
dependency that's missing, but I am trying to convince them that the
low-level glib should not end up depending on a UI library...
Hence for the moment, I absolutely cannot use glib network I/O. Can
you tell me, since you've written libgovirt, do you think it's
possible to add functionality to *it* rather than writing workarounds
for client software? I could work around this issue in aSPICE, but
that would not help for any other client on any other platform that
doesn't have GTK.
Regardless of whether you do agree it's best if govirt either stopped
relying on glib network file I/O or had an option to use a different
method, what library would you say would be best suited to replace all
the network file I/O operations that you have in govirt with a
download - local file I/O sequence? Libcurl comes to mind, but
perhaps libsoup is better suited for the purpose in your opinion?
Could you try what I suggested in
http://lists.freedesktop.org/archives/spice-devel/2013-September/014430.html
? I think gvfs is only used if you use the helpers to fetch the
certificate, and the rest of the code is just doing calls into
librest/libsoup which I think are not using gio/gvfs.
If this is a correct, then I think it's not a big issue that you don't
have
gvfs on your platform. If it is, I'll have to look where/how it's used to
figure out how to workaround this.
Hope that helps,
Christophe
--
The conscious mind has only one thread of execution.
--
The conscious mind has only one thread of execution.
--
The conscious mind has only one thread of execution.
___
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/spice-devel
