serious termios flaw?
strauman at slac.stanford.edu
Wed Jun 28 23:14:31 UTC 2006
Till Straumann wrote:
> 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.
> Thomas Doerfler wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 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
>> 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?
>> - --
>> - --------------------------------------------
>> IMD Ingenieurbuero fuer Microcomputertechnik
>> Thomas Doerfler Herbststrasse 8
>> D-82178 Puchheim Germany
>> email: Thomas.Doerfler at imd-systems.de
>> PGP public key available at:
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.3 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>> -----END PGP SIGNATURE-----
More information about the users