Re: Serial port: tcgetattr and tcsetattr

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

Date: Thu, 04 Aug 2005 13:50:37 +0100

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

>>> The Linux implementation of termios adds another element to
>>> configure line disciplines, c_line. For normal TTY use, the
>>> correct value is 0. Using memset(3) to clear the entire struct,
>>> the program will always work, even if the programmer does not
>>> know that c_line exists!
>>>
>>> If instead the program uses POSIXly correct initialization and
>>> does *not* set c_line (to N_TTY, defined as 0 in sys/ioctl.h),
>>> the program will probably work... but there *will* come a day
>>> when the port was being used for PPP or ISDN, and c_line will
>>> end up not being 0. The program will then fail.
>>
>>This is the nub of them problem. POSIX only guarantees that
>>conforming systems behave as it describes when applications are
>>run in a "conforming environment". There can be many different
>>contributing factors that determine what a conforming environment
>>is. In the case in point, one of those factors would be whether
>>or not a non-POSIX application such as pppd has used the serial
>>line and left it in a state where some non-POSIX flags are set
>>which tell the system to behave in a non-POSIX-conforming way.
>
> That is not correct. Regardless of whether the port was used by
> a "POSIX application" or not, there is *no* requirement or
> expectation that *any* particular state will be maintained for
> the port when that application is finished.
>
> And there is no such thing as non-compliance due to "non-POSIX
> flags" because POSIX explicitly allows additional options,
> flags, or elements to be added to the termios struct.
>
> There is no such thing as a termios flag that will "tell the
> system to behave in a non-POSIX-conforming way", because POSIX
> does not limit how a serial port behaves.

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

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.

>>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
other systems without writing a test program, as none of the
other non-Linux systems I have access to have something usable
connected to a serial port.

I seem to recall that SVR4 also set the flags to defaults, as
printer interface scripts had to be careful about keeping serial
ports open when setting flags with stty. I assume that current
descendents of SVR4 would still do the same. 

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

Relevant Pages

  • Re: Serial port: tcgetattr and tcsetattr
    ... >POSIX then obviously POSIX no longer makes any guarantee about what ... >whenever a conforming application is run in a conforming environment. ... >POSIX-defined flags and are run in a conforming environment). ... *must* *ignore* the way HP-UX set termios options on close, ...
    (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
    ... >>terminal interfaces behave (in a conforming environment). ... >>terminal flags are run in a conforming environment. ... > There is no requirement that applications use only the POSIX-defined ... POSIX then obviously POSIX no longer makes any guarantee about what ...
    (comp.unix.programmer)