termios

[Wolfram Wadepohl]

Joel Sherrill schrieb:

>Thomas Doerfler wrote:
>  
>
>>Hello,
>>
>>I think you refer to the loop starting with
>>
>>                while (tty->rawInBuf.Head != tty->rawInBuf.Tail) {
>>
>>in function "fillBufferQueue" in termios.c.
>>
>>IMHO a solution would be to limit the loop to the cases, when
>>the variable "wait" ist still TRUE, so a replacement for the
>>upper line would be
>>
>>                while (wait && (tty->rawInBuf.Head != tty->rawInBuf.Tail)) {
>>    
>>
>
>I think either will work but changing the semantics of the checks being
>made
>separately scares me a bit without doing more analysis.
>
There is adiffernce between my solution and Thomas'. with the inserted 
break only in cannonical processing input is terminated with either a 
NL, EOF, EOL or EOL2. in non cannonical processing as much as available 
characters are returned to the application. IMO this the right way, 
because in non-cannonical mode there is only a lower limit of chars 
VMIN, termios should return as much characters as available.

>I think Wolfram's solution is correct and less likely to perturb things.
>
>Can one of you file a PR once the patch is tested?
>
>FWIW my first job out of college was porting the System V TTY driver
>to an embedded environment.  It was an intelligent serial controller
>and the card pretty closely mapped section 2 system calls.  The code
>was incredibly complicated and the RTEMS termios driver is a piece of
>cake to read compared to that. :)
>
>--joel
>
>
>  
>
>>wkr,
>>        Thomas Doerfler.
>>
>>    
>>
>>>Hello,
>>>
>>>we are struggling with the termios system in the moment and we need the
>>>help of the community.
>>>either there is a missunderstanding of cannonical processing by us or a
>>>real bug in the termio system.
>>>the function fillBufferQuue() is responsible to transfer from raw input
>>>buffer into cooked buffer and all the control character processing is
>>>handled by iproc(). when iproc() signals a completed line by returning a
>>>one, fillBufferQueue does not return to the caller with this line in the
>>>cooked buffer, but remains in its loop and appends all further
>>>characters (after cannonical processing) to the cooked buffer. IMHO
>>>fillBufferQueue should return immediately after an NL, EOF, EOL or EOL2
>>>was added to cooked buffer.
>>>
>>>this behaviour could be accomplished by adding a break instruction after
>>>the wait = 0; instruction after calling siproc() in cannonical processing.
>>>      
>>>
>>>--
>>>Schöne Grüße aus Reutlingen
>>>
>>>Wolfram Wadepohl
>>>Entwicklung
>>>
>>>--
>>>INDUMAT GmbH & Co. KG
>>>Transport- und Lagersysteme
>>>Dieselstraße 6
>>>D-72770 Reutlingen - Betzingen
>>>
>>>Tel.  +49 (0)71 21/5 14-2 89
>>>Fax   +49 (0)71 21/5 14-2 99
>>>eMail W.Wadepohl at indumat.de
>>>WWW   http://www.indumat.de
>>>--
>>>
>>>Bitte senden Sie mir keine Word- oder PowerPoint- (tm Microsoft)  Anhänge.
>>>Senden Sie mir einfachen Text, HTML oder PDF.
>>>Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html
>>>
>>>
>>>      
>>>
>>--------------------------------------------
>>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/pgp_keys.htm
>>    
>>
>
>  
>


-- 
Schöne Grüße aus Reutlingen

Wolfram Wadepohl
Entwicklung

--
INDUMAT GmbH & Co. KG
Transport- und Lagersysteme
Dieselstraße 6
D-72770 Reutlingen - Betzingen

Tel.  +49 (0)71 21/5 14-2 89
Fax   +49 (0)71 21/5 14-2 99
eMail W.Wadepohl at indumat.de
WWW   http://www.indumat.de
--

Bitte senden Sie mir keine Word- oder PowerPoint- (tm Microsoft)  Anhänge.
Senden Sie mir einfachen Text, HTML oder PDF. 
Siehe http://www.fsf.org/philosophy/no-word-attachments.de.html