[Qemu-devel] Two question on serial port emulation

[Qemu-devel] Two question on serial port emulation

[Jiang, Yunhong]

Hi, all
    I'm using qemu on linux, and I have two questions on the serial port
emulation. The serial port means the hardware serial port (/dev/ttyS0 on
Linux).

    1) Currently tty_serial_init()  set the c_oflags as following:
        tty.c_oflag |= OPOST
  but it didn't clear the ONLCR/ONLRET etc. This may cause some problem
on binary transfer. For example, when transfer "0x0d 0x0a" for "0x0a".
Following patch may fix this problem, although I'm not sure if we clear
OPOST, do we still need to clear ONLCR/OCRNL etc bits.
 
--- vl.c        2006-05-04 04:32:58.000000000 +0800
+++ ../qemu-0.8.1_bogus/vl.c    2006-06-01 22:34:09.000000000 +0800
@@ -1586,7 +1586,8 @@
 
     tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
                           |INLCR|IGNCR|ICRNL|IXON);
-    tty.c_oflag |= OPOST;
+    tty.c_oflag &= ~(ONLCR | OCRNL | ONOCR |ONLRET) ;
+    tty.c_oflag &= ~OPOST;
     tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
     tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS);
     switch(data_bits) {

2) Currently all write to the serial port will through unix_write().
Considering : a) if the return value is -EAGAIN, it will not try to
re-write this again. b) all write will return immetiately. So when guest
try to write a lot of data continuously, like using zmodem to transfer
file or using serial port for debugger, it may cause application failure
(the data is write successfuly from guest point of view, while it failed
on the host environment). I changed the write process to multi-thread,
but I don't think it is a good method, so how do you think of these?
 
 
Thanks
Yunhong Jiang

Re: [Qemu-devel] Two question on serial port emulation

[Fabrice Bellard]

Jiang, Yunhong wrote:
> Hi, all
>     I'm using qemu on linux, and I have two questions on the serial port
> emulation. The serial port means the hardware serial port (/dev/ttyS0 on
> Linux).
> 
>     1) Currently tty_serial_init()  set the c_oflags as following:
>         tty.c_oflag |= OPOST
>   but it didn't clear the ONLCR/ONLRET etc. This may cause some problem
> on binary transfer. For example, when transfer "0x0d 0x0a" for "0x0a".
> Following patch may fix this problem, although I'm not sure if we clear
> OPOST, do we still need to clear ONLCR/OCRNL etc bits.
>  
> --- vl.c        2006-05-04 04:32:58.000000000 +0800
> +++ ../qemu-0.8.1_bogus/vl.c    2006-06-01 22:34:09.000000000 +0800
> @@ -1586,7 +1586,8 @@
>  
>      tty.c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP
>                            |INLCR|IGNCR|ICRNL|IXON);
> -    tty.c_oflag |= OPOST;
> +    tty.c_oflag &= ~(ONLCR | OCRNL | ONOCR |ONLRET) ;
> +    tty.c_oflag &= ~OPOST;
>      tty.c_lflag &= ~(ECHO|ECHONL|ICANON|IEXTEN|ISIG);
>      tty.c_cflag &= ~(CSIZE|PARENB|PARODD|CRTSCTS);
>      switch(data_bits) {

So forcing all the flags to known values may be even better !

> 2) Currently all write to the serial port will through unix_write().
> Considering : a) if the return value is -EAGAIN, it will not try to
> re-write this again. b) all write will return immetiately. So when guest
> try to write a lot of data continuously, like using zmodem to transfer
> file or using serial port for debugger, it may cause application failure
> (the data is write successfuly from guest point of view, while it failed
> on the host environment). I changed the write process to multi-thread,
> but I don't think it is a good method, so how do you think of these?

You should use the callback based I/Os. An output FIFO must be 
maintained in the serial driver itself. Unfortunately an API is missing 
on the QEMU char devices to do proper asynchronous outputs.

Fabrice.