Re: Serial port: tcgetattr and tcsetattr

From: Geoff Clare (geoff_at_clare.See-My-Signature.invalid)
Date: 08/05/05 

Date: Fri, 05 Aug 2005 13:50:09 +0100

floyd@apaflo.com (Floyd L. Davidson) wrote, on Thu, 04 Aug 2005:

>>POSIX contains a very detailed description of exactly how
>>terminal interfaces behave (in a conforming environment).
>>It "limits" the behaviour by requiring systems to behave in the way
>>it describes when applications which only use the POSIX-defined
>>terminal flags are run in a conforming environment.
>
> There is no requirement that applications use only the POSIX-defined
> terminal flags.

True, but once an application uses a flag that is not defined by
POSIX then obviously POSIX no longer makes any guarantee about what
the behaviour will be.

>>The point about POSIX behaviour only being guaranteed for applications
>>run in a "conforming environment" does not only apply to the terminal
>>interface. It is a fundamental principle that underlies the entire
>>POSIX standard.
>
> You are saying that POSIX has a "detailed description" of
> exactly how the termios configuration should be *after* a POSIX
> compliant program exits? (And not when a non-POSIX program has
> run???)

No. I'm saying it describes how the terminal interface behaves
whenever a conforming application is run in a conforming environment.
If one particular terminal is used by one application and then
later by another application, then both applications will get the
behaviour described by POSIX (provided they both use only the
POSIX-defined flags and are run in a conforming environment).

>>>>Some systems solve this problem by always initialising serial
>>>>lines to a default sane set of flags on the first open (or maybe
>>>>it's on last close - there's no way to tell the difference).
>>>>I don't know why Linux doesn't do that.
>>>
>>> I don't know of *any* POSIX system which does that. Certainly
>>> that is not a POSIX requirement, or even a hinted at as being
>>> useful (which it is not).
>>
>>HP-UX certainly does it - I just checked. I can't easily check
> ...
>>I seem to recall that SVR4 also set the flags to defaults, as
> ...
>
> And here you are saying you can only think of possibly two such
> implementations that set flags on exit.

I gave two examples of systems that I am either certain or fairly
sure set the flags to defaults. I believe there are probably more.

> Either POSIX requires it, or doesn't.

It doesn't require the flags to be reset to defaults, nor did I claim
that it does. (Note the word "some" in the quote above: "Some systems
solve ...")

> And in fact, when we look at what POSIX does say about setting
> those flags to some default, it turns out to be 1) more confusing
> than what I've previously said that the initialization of
> configuration flags is, and 2) not nearly as limiting as you
> have claimed (though it is exactly what your example implies,
> rather than what you've stated):
[snip]
> Just as an implementation is free to add members to the termios
> structure, it may or may not change terminal attributes when
> close() is called for the file descriptor. Hence either action
> is allowed, and the Linux behavior (including after pppd or some
> similar non-POSIX program has been run) is just as acceptable as
> the HP-UX behavior that you've cited.

Yes, both are allowed by POSIX. I never claimed otherwise.

The difference is that on systems that reset the flags to defaults,
applications always see the POSIX behaviour. On systems like Linux
that don't set the flags to defaults, applications may or may not
see the POSIX behaviour depending on previous usage of the serial
port. The way this situation is handled by the standard is that
if something is done to the serial port such that the next POSIX
application will not see the POSIX behaviour then that application
is not being run in a "conforming environment". Applications
can deal with this either by resetting all flags using memset(),
which is forbidden by POSIX and therefore runs the risk of causing
incorrect behaviour on some systems, or by ensuring that the serial
port is only ever used by POSIX applications (or if it is used by
a non-POSIX application such as pppd then to require that some
external method is used to reinstate a "conforming environment" for
that port before the next POSIX application uses it). 

-- 
Geoff Clare <netnews@gclare.org.uk>

Relevant Pages

  • Re: Serial port: tcgetattr and tcsetattr
    ... run in a "conforming environment". ... or not a non-POSIX application such as pppd has used the serial ... lines to a default sane set of flags on the first open (or maybe ... line is only ever used by POSIX applications (or POSIX-friendly ...
    (comp.unix.programmer)
  • Re: Serial port: tcgetattr and tcsetattr
    ... >> flags, or elements to be added to the termios struct. ... POSIX contains a very detailed description of exactly how ... exactly how the termios configuration should be *after* a POSIX ... behavior of options in the termios structure. ...
    (comp.unix.programmer)
  • RE: *at family of syscalls in FreeBSD
    ... getting parameters/behavior right seemed a little more useful than preparing ... EBADF if the path isn't an absolute path AND the fd is invalid, ... POSIX doesn't seem to have rmdirat (yes, ... Looks like POSIX just overloads unlinkatwith a new flags parameter ...
    (freebsd-arch)
  • Re: *at family of syscalls in FreeBSD
    ... necessarily stable in the standard. ... linux implements flags too. ... POSIX doesn't seem to have rmdirat (yes, ... Can't say that's my favorite API, ...
    (freebsd-arch)
  • Re: Serial port: tcgetattr and tcsetattr
    ... >>contributing factors that determine what a conforming environment ... > flags" because POSIX explicitly allows additional options, ... > flags, or elements to be added to the termios struct. ... terminal interfaces behave. ...
    (comp.unix.programmer)