Hi,
On Tue, 4 May 2010 at 11:23, Anthony Liguori wrote:
0.11.0 is pretty old. Please update your patch against the latest git.
Ok, will do.
I'm not sure we're doing the wrong thing right now.
Well, I think it just can't be correct, that an IPv6-enabled process
running on a dual-stack
On 05/04/2010 03:44 PM, Reinhard Max wrote:
Hi,
On Tue, 4 May 2010 at 11:23, Anthony Liguori wrote:
0.11.0 is pretty old. Please update your patch against the latest git.
Ok, will do.
I'm not sure we're doing the wrong thing right now.
Well, I think it just can't be correct, that an
On 05/04/10 18:23, Anthony Liguori wrote:
On 05/04/2010 08:49 AM, Reinhard Max wrote:
Hi,
I am maintaining the tightvnc package for openSUSE and was recently
confronted with an alleged vnc problem with QWMU that turned out to be
a shortcoming in QEMU's code for handling TCP server sockets,
On 05/04/2010 04:47 PM, Gerd Hoffmann wrote:
On 05/04/10 18:23, Anthony Liguori wrote:
On 05/04/2010 08:49 AM, Reinhard Max wrote:
Hi,
I am maintaining the tightvnc package for openSUSE and was recently
confronted with an alleged vnc problem with QWMU that turned out to be
a shortcoming in
On Tue, 4 May 2010 at 23:47, Gerd Hoffmann wrote:
My tigervnc (tightvnc successor) has IPv6 support and handles this
just fine.
Well, as I wrote, the code is not just used for vnc, but also for
server sockets that (if I got that right) could be connected from
telnet or netcat
On Tue, May 04, 2010 at 03:49:50PM +0200, Reinhard Max wrote:
Hi,
I am maintaining the tightvnc package for openSUSE and was recently
confronted with an alleged vnc problem with QWMU that turned out to be
a shortcoming in QEMU's code for handling TCP server sockets, which is
used by the
Hi,
When going for multiple listening sockets in qemu we have to figure
how we'll handle this in a number of places as there is no single
listening address any more.
Well, that's what my patch is about.
Sure.
Did you take a look at it?
Briefly, yes. Overall it looks sensible to me.
Hi,
On Wed, 5 May 2010 at 10:53, Gerd Hoffmann wrote:
Noticed that it probably should get a few helper functions to handle
FdLists to avoid the quite simliar open-coded loop-over-all-fds
loops all over the place.
indeed, thanks for the hint. I now have functions to create a new list
Hi,
You'll run into qmp for sure when forward-porting the patches to the
latest qemu bits. It is the machine-readable version of the monitor
protocol (in qemu 0.12+).
I guess that's the qemu_opt_set() calls at the end of inet_listen_opts()?
See docs in QMP/*, the changes in monitor.c and
On Tue, May 04, 2010 at 04:50:34PM -0500, Anthony Liguori wrote:
On 05/04/2010 04:47 PM, Gerd Hoffmann wrote:
On 05/04/10 18:23, Anthony Liguori wrote:
On 05/04/2010 08:49 AM, Reinhard Max wrote:
Hi,
I am maintaining the tightvnc package for openSUSE and was recently
confronted with an
On Wed, May 05, 2010 at 10:53:00AM +0200, Gerd Hoffmann wrote:
Hi,
When going for multiple listening sockets in qemu we have to figure
how we'll handle this in a number of places as there is no single
listening address any more.
Well, that's what my patch is about.
Sure.
Did you
Hi,
I've attached a revised version of the patch against git as of this
morning.
It has even more FIXMEs in it than the previous version, because of
the changes that went into QEMU since 0.11.0 and I think I'll have to
leave those to you guys who are more familiar with QEMUs internals
than
Hi,
I am maintaining the tightvnc package for openSUSE and was recently
confronted with an alleged vnc problem with QWMU that turned out to be
a shortcoming in QEMU's code for handling TCP server sockets, which is
used by the vnc and char modules.
The problem occurs when the address to
On 05/04/2010 08:49 AM, Reinhard Max wrote:
Hi,
I am maintaining the tightvnc package for openSUSE and was recently
confronted with an alleged vnc problem with QWMU that turned out to be
a shortcoming in QEMU's code for handling TCP server sockets, which is
used by the vnc and char modules.
14 matches
Mail list logo
