On Sun, 2014-03-30 at 12:52 -0700, Linus Torvalds wrote: > On Sun, Mar 30, 2014 at 12:14 PM, Venkatesh Shukla IIT BHU > <[email protected]> wrote: > The kernel didn't actually complain at all, and what seems to happen > is that glibc tries to be "helpful", and after it has done the TCSETC > it does a TCGETC and compares the result. And notices that the PARENB > > And it looks like it notices that it tried to *set* c_cflags to 0xfbb > but then it reads back c_cflags as 0xebb. > > The difference is octal 0400, which is PARENB. Because under Linux, > pty's always do > > tty->termios.c_cflag &= ~(CSIZE | PARENB); > tty->termios.c_cflag |= (CS8 | CREAD); > > and glibc tries to be "helpful" and notice that some of the settings > don't stick. For no good reason. > > Now, I'm not saying that the kernel necessarily has to do the above > for pty's (it could just ignore the bits, and not set them to what > pty's actually do), but Linux has always done the above, so it's some > idiotic change in glibc that now causes problems. > > Don't ask me why the glibc people decided to "improve" on tcsetattr() this > way. > > Funnily enough, I do *not* find this in the glibc sources for > tcsetattr (sysdeps/unix/sysv/linux/tcsetattr.c): > > > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/tcsetattr.c > > so I wonder if this is some Fedora "feature".
Hmm, that would be even more sad. What do you recommend as workaround? I don't see anything wrong with what the kernel does and while I don't know why glibc would be so 'helpful', I don't have enough data to argue one way or another. Should libdivecomputer ignore the error when on a PTY? /D _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
