I don't really know the gdb code, but I'm surprised it really has multiple different "serial" backends. I would have thought that after opening the fd, you would treat them all about the same. If tcsetattr et al work on it, then you set the baud rate and whatever, if they say ENOTTY then fine. It might make sense to default to a short read timeout for an actual serial port (or UDP port), which might be unplugged or the other end dead, or whatever; and to an infinite timeout for a non-tty, which should more presumably have its fd shut down and read EOF or EPIPE or whatever when the stub goes away, and otherwise perhaps the stub is just taking that long. But aside from that, I don't know why you wouldn't treat all kinds of remote protocol fd's the same wrt select/poll and blocking/nonblocking reads/writes, be they serial-port fds, "pipe" socketpair sockets, network sockets, or fds to a new magic file that pretends to be a tty or a socket or whatever (or even a disk file of canned response playback!).
Thanks, Roland