|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [Qemu-devel] [PATCH 2/2] open ptys in non-blocking mode.
[Crossposting to xen-devel]
Ian, we need something like this for qemu-xen (or ioemu-remote or
whatever it's called now). Currently you must attach to the console of a
domain, otherwise it won't boot up and keep hanging in a blocking write
because the buffer is full.
The old ioemu had a hack in unix_write (doing a select before the write)
which you didn't merge into qemu-xen. In fact, I noticed that you even
removed that function entirely and I'm wondering why.
Kevin
Gerd Hoffmann schrieb:
> Otherwise qemu will hang in case nobody connects to the pty and the
> guests prints enougth messages to fill up the buffer (which is 4k
> in linux).
>
> Downside is that data may get lost in case the reader is too slow.
>
> Ideally we could detect whenever someone is connected to the other end
> of the pseudo tty and write data only in connected mode (like it is done
> for tcp/telnet). I'm not aware of any way to accomplish that though.
>
> Signed-off-by: Gerd Hoffmann <kraxel@xxxxxxxxxx>
> ---
> vl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 587b91c..adc8f5f 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -2468,6 +2468,7 @@ static CharDriverState *qemu_chr_open_pty(void)
> /* Set raw attributes on the pty. */
> cfmakeraw(&tty);
> tcsetattr(slave_fd, TCSAFLUSH, &tty);
> + socket_set_nonblock(master_fd);
>
> fprintf(stderr, "char device redirected to %s\n", ptsname(master_fd));
> return qemu_chr_open_fd(master_fd, master_fd);
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- [Xen-devel] Re: [Qemu-devel] [PATCH 2/2] open ptys in non-blocking mode.,
Kevin Wolf <=
|
|
|
|
|