serious termios flaw?

[Till Straumann]

Till Straumann wrote:

> Thomas.
>
> Thanks for clarifying.
> Where I seem to have problems is 'ppp_tty.c:pppstart,
> lines 637-648'.
> I can't see how characters dropped by the 'write' routine
> are saved and written later.

I'm even more confident now that this is true. I got lots of
dropped packets (as a matter of fact: all packets were
missing at least one char and were dropped for FCS mismatch).

Reducing the number of chars passed to 'write' fixed that.
I have now filed PR1113 with a patch. Hopefully someone
can look at it.

-- T.

>
> Till
>
> Thomas Doerfler wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Till,
>>
>> I am not sure which mode of termios drivers you are referring to.
>> Generally the termios driver API can pass multiple characters to a write
>> routine. in polled mode, the driver's polled write function must send
>> all given characters to the hardware. I can see this implemented e.g. in
>> the "pc386" BSP in console.c:
>>
>> static int
>> ibmpc_console_write(int minor, const char *buf, int len)
>> {
>>  int count;
>>  for (count = 0; count < len; count++)
>>  {
>>    _IBMPC_outch( buf[ count ] );
>>    if( buf[ count ] == '\n')
>>      _IBMPC_outch( '\r' );            /* LF = LF + CR */
>>  }
>>  return 0;
>> }
>>
>> In interrput mode, termios can pass a rather long buffer to the driver's
>> write function, but the driver is not forced to handle that size.
>> Instead, when the driver's interrupt function calls
>> "rtems_termios_dequeue_characters", it passes to termios how many
>> characters have been sent out to the device. Simple devices without FIFO
>> or DMA support may always pass a "1" to this function, then termios will
>> pass the rest of the send buffer once more to the device driver's write
>> function.
>>
>> wkr,
>> Thomas.
>>
>>
>>
>>
>>
>> Till Straumann schrieb:
>>  
>>
>>> I found that termios (and, BTW: ppp_tty) call
>>> the low-level driver's 'write' routine, possibly supplying
>>> more than one character and without checking
>>> the return code of 'write'.
>>>
>>> Most UART drivers OTOH (I checked i386, ppc, uC5282[coldfire]),
>>> silently discard anything after the first char in the buffer.
>>> This is not reflected in the return code.
>>>
>>> IMO, the low-level drivers should return the # of chars
>>> actually written and the upper layers should check for and
>>> handle this case.
>>>
>>> Am I missing something?
>>>
>>> Till
>>>   
>>
>>
>>
>> - --
>> - --------------------------------------------
>> IMD Ingenieurbuero fuer Microcomputertechnik
>> Thomas Doerfler           Herbststrasse 8
>> D-82178 Puchheim          Germany
>> email:    Thomas.Doerfler at imd-systems.de
>> PGP public key available at:
>>     http://www.imd-systems.de/pgpkey_en.html
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.3 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>
>> iD8DBQFEnlSqwHyg4bDtfjQRAgA8AJ9/QLrB4jL5CwglhCZATZ9JTaeQJgCfRYsN
>> pI4KKdv+/L8xSH1H8XkSXqU=
>> =YRSP
>> -----END PGP SIGNATURE-----
>>  
>>
>
>