Re: tcsetattr/ioctl problem causes stty tests to fail

Jim Meyering (meyering@ascend.com)
17 Feb 1999 08:32:55 -0600


Andries.Brouwer@cwi.nl writes:

| Jim Meyering writes:
|
| > 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

Hi Andries,

Thanks for the reply.

| 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]."

In the example code I sent, there was only one action requested
(enable parity), and that wasn't performed.

| as saying that the tcsetattr() should have returned -1, but it is not
| entirely clear what the definition of `requested action' is.

IMHO, the requested action in my example code is `enable parity (PARENB)'.

| Concerning this return value, POSIX.1 B7.2 can be read so that 0 is permissible.

The way I read it, if the tcsetattr call requests a single change
(e.g., set the PARENB bit or reset the CREAD one), but that single
request cannot be performed, then it must return nonzero. However
if the request includes more than one change from the current state,
and at least one of those request is honored, then it must return zero.

| A different point of view is that POSIX does not describe pseudottys.
| Or, that the pty `hardware' does not `support' the PARENB setting.

I think the semantics of POSIX tcsetattr are clear and independent of
pseudo ttys or whether hardware supports that setting.

| So, I think the point is debatable.
| No reason to call it a bug.

I didn't call it a bug. In saying I've found a problem, I didn't
mean to impugn anyone's code. Sorry if it sounded that way.

| 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.

But that is not the behavior of any released version of stty.
They don't exit nonzero because tcsetattr succeeds. It's only
in tracking this down that I added the hook to make it fail.

The diagnostic is misleading. The single requested operation
was not performed.

Is there any chance tcsetattr can be adjusted to return an indication
of its failure in this case?

-
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/