On Thu, Sep 19, 2013 at 12:59:33PM -0400, Jonathan Lebon wrote:
> poll() will be listening for i/o on the libvirt socket as well
as
> stdin, so it'll see incoming I/O from the guest.
That's strange, that's not what I'm seeing when running it step-by-step. I
see
poll() hanging regardless of guest events. There are indeed two fds in the
array (stdin and the other one being the libvirt socket I suppose), but in all
cases, I never observed an event occurring on the libvirt socket. Am I missing
a call to something here?
Note that I'm using 1.0.5.5 (daemon and library). Could things have changed
recently?
We've had quite a few changes sinc that release, so its always possible,
but at the smae time 'virsh console' has been using this code along time
and no one has complained about the problem you describe.
> One relevant thing is that stdio is line buffered by default and you
> aren't putting it into raw mode like virsh console does. This will
> delay I/O on the stdio streams.
That's a good point. But since all the messages between host and guest end
in newlines, that shouldn't be an issue, right? Anyway, I can see the lines
from stdin making it to virStreamSend() upon the first <Enter>. And from the
other side, it's safe to assume socat sends the data after the first <Enter>
as well (since it works fine with socat to socat directly on the socket/port).
As a test why not try hacking virsh console so that it connects to your
virtio serial port, instead of a console. If we assume 'virsh console'
is bug-free, that would let you identify whether the flaw is in your host
code, or the guest side.
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|