RE: Interpretation of termios flags on a serial driver

[Henrique Gobbi <henrique.gobbi@cyclades.com>]

Hello Ed !
Thanks for the feedback. 

Please read my coments (doubts actually) below:

> > 4 - INPCK flag: What's the purpose of this flag. What's the 
> > diference in 
> > relation to IGNPAR;
>      If INPCK is set, input parity checking  is  enabled.      If
>      INPCK is  not  set, input parity checking is disabled.  This
>      allows output parity generation without input parity errors.
>      Note  that  whether input parity checking is enabled or dis-
>      abled is independent of whether parity detection is  enabled
>      or disabled. If parity detection is enabled but input parity
>      checking is disabled, the hardware to which the terminal  is
>      connected  will  recognize  the parity bit, but the terminal
>      special file will not check whether this is set correctly or
>      not.
> 
>      If IGNPAR is set, a  byte  with  framing  or  parity  errors
>      (other than break) is ignored. This means that the data byte
>      with the error is thrown away  by the  driver as if the byte
>      had never been received. 
> 
> In short,
> If INPCK is _not_ set, then all received data bytes will be delivered 
> to the user level, regardless of parity errors.
> If IGNPAR is set, then only received data bytes that do not have 
> parity errors will be delivered to the user level.
> If PARENB is _not_ set, then the receiver hardware will not detect 
> bad parity, so all received data bytes are considered free of errors. 
> Since there are no data bytes with associated error indications, 
> setting IGNPAR would have no effect. All of the data are considered 
> error free.

Your explanation makes sense to me. With this information I built the
table:
   IGNPAR    INPCK         ACTION:
     0         0           Deliver all data to the user-level
     0         1           Check parity. Discard erroneous bytes
     1         0           ????
     1         1           Check parity. Discard erroneous bytes 

What goes on ????   ?

> > 5 - If the TTY knows the data status (PARITY, FRAMING, 
> > OVERRUN, NORMAL), 
> > why the driver has to deal with the flag IGNPAR. Shouldn't 
> > the TTY being 
> > doing it ?
> 
> Not sure I understand the question. Received data does not carry any
> information about errors with it after it leaves the driver, unless 
> PARMRK is set. 

When the driver copy the data from the controler to the flip buffer it
copies the data to the buffer tty->flip.char_buf_ptr and it set a flag
(TTY_NORMAL, TTY_PARITY, TTY_FRAME, etc) on the buffer
tty->flip.flag_buf_ptr telling the TTY how this byte was received. So
the TTY knows if certain byte was problematic or not. Did you understand
my doubt know ?

Thanks for your patience
Henrique