gdbserver vs. serial ports

gdbserver vs. serial ports

[Daniel Jacobowitz]

I see that in remote-utils.c, we deliberately set VMIN and VTIME to 0 if we
open a serial port.  On an i386-linux (2.4) host, this has the effect of
making read() return 0 if no data is available.  We see the 0 and
immediately decide that it's an EOF, and close/reopen the serial port.

I don't have a lot of experience with serial programming.  Should we be
setting VMIN differently, or should we treat read() returning 0 differently? 
It looks like ser-unix.c treats them read() returning 0 as a timeout and
sets VMIN appropriately before calling read().  Which raises the question -
does anyone know if gdbserver actually worked over serial ports? :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver vs. serial ports

[J.T. Conklin]

>>>>> "Daniel" == Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:
Daniel> I don't have a lot of experience with serial programming.
Daniel> Should we be setting VMIN differently, or should we treat
Daniel> read() returning 0 differently?  It looks like ser-unix.c
Daniel> treats them read() returning 0 as a timeout and sets VMIN
Daniel> appropriately before calling read().  Which raises the
Daniel> question - does anyone know if gdbserver actually worked over
Daniel> serial ports? :)

The TERMIOS and TERMIO cases put the tty in raw + non blocking mode,
but the SGTTY case only puts the tty in raw mode.  It's possible, if
this ever worked, that it was only tested on an very old machine pre-
termios and termio serial disciplines.

Since the current model of gdbserver and the sample gdb stubs do not
make any allowances for timeouts, I think it's reasonable to use the
default VMIN and VTIME, which should result in a blocking read().

If we're really going to support serial i/o in gdbserver, we probably
need to provide options for setting the baud rate, etc.

        --jtc

-- 
J.T. Conklin
RedBack Networks