I don't know this area well, but considering that ser-unix.c is just
chock full of tty-related goo, I think it is probably important for
something. My impression is that this API is not just used for target
communication but also for manipulating gdb's own terminal.
Ah, I see.
I've
Roland However, I think the test you probably want is !S_ISCHR.
Thanks. I wasn't sure.
Roland Actually, better yet, just make it !isatty (fd).
Ok.
I made a new branch, 'archer-ugdb'.
This patch is there. (Actually 2 patches due to me not reading
carefully enough the first time -- but
On 08/13, Tom Tromey wrote:
Roland However, I think the test you probably want is !S_ISCHR.
Thanks. I wasn't sure.
Roland Actually, better yet, just make it !isatty (fd).
Ok.
Good. IIUC, this also allows to remove the ugly return 0
to pretend TCGETS/TCSETS/TCFLSH works from -ioctl().
I
I seem to understand the problem(s). I am a bit surprized. Basically
I have the questions about almost every utrace_ function. I'll try
to recheck and summarize my concerns tomorrow with a fresh head, I
hope I missed something.
Ok. That stuff about pure kernel implementation issues doesn't
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
Roland I don't really know the gdb code, but I'm surprised it really
Roland has multiple different serial backends.
I don't know this area well, but considering that ser-unix.c is just
chock full of tty-related goo, I think it is probably important for
something. My impression is that this API
