> I'm wondering if I've found a problem with the way the kernel
> handles the ioctl calls resulting from my call to tcsetattr.
Hmm. If I am not mistaken, the behaviour you see is caused
by the routine
static void pty_set_termios(struct tty_struct *tty, struct termios *old_termios)
{
tty->termios->c_cflag &= ~(CSIZE | PARENB);
tty->termios->c_cflag |= (CS8 | CREAD);
}
in pty.c. (Linux kernel source, since 2.0.1.)
In other words, I expect that you'll see it only on a pseudotty.
I don't know whether it can be regarded as a problem.
One may read the lines
"The tcsetattr() function shall return success if it was able
to perform any of the requested actions, even if some of the requested
actions could not be performed. It shall set all the attributes that
the implementation supports as requested and leave all the attributes
not supported by the implementation unchanged. If no part
of the request can be honoured, it will return -1 and set errno to [EINVAL]."
as saying that the tcsetattr() should have returned -1, but it is not
entirely clear what the definition of `requested action' is.
Concerning this return value, POSIX.1 B7.2 can be read so that 0 is permissible.
A different point of view is that POSIX does not describe pseudottys.
Or, that the pty `hardware' does not `support' the PARENB setting.
So, I think the point is debatable.
No reason to call it a bug.
And as to your demo:
$ stty parenb
stty: standard input: unable to perform all requested operations
[Exit 1]
$
maybe this is perfect behaviour: the parenb setting is not changed
and stty tells the user about that.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/