RE: n_tty.c driver patch (semantic and performance correction) (a ll recent versions)

Hi Robert,

On Sat, June 15, 2002, Robert White wrote:

The n_tty line discipline module contains a "semantic error" 
that limits its speed and usefullness in many uses.  The 
attached patch directly addresses serial performance in a 
completely backwards-compatable way.

In particular, the current handling of VMIN hugely limits, 
complicates, and/or slows down optimal serial use.  The most 
obvius example is that if you call read(2) with a buffer size 
less than the current value of VMIN, the line discipline will 
insist that the read call wait for characters that can not be 
returned to that call.  The POSIX standard is silent on the 
subject of whether this is right or wrong.  Common sense says 
it is wrong.

Ten years ago, I would have agreed with you. I suggested a very 
similar change for VTIME=0;VMIN>0 behavior back then, while we 
were porting SVR4 to proprietary hardware. This was for 
compatibility with the way reads were handled on a previous 
non-un*x product. It was deemed a spec violation, so we added an 
ioctl to implement the compatible behavior. 

Does the spec say that VMIN behavior depends on the size of a 
blocking read? No, it says that the read completes when VMIN or 
more characters have been received. If VMIN is three and two 
characters have been received, completing a blocking read of any 
size is a violation. Should we also add a "read buffer size" 
parameter to select and poll, etc. so they can report that read 
data is available before satisfying VMIN, too? 

Ted, Russell, please weigh in on this. 

Best regards,
Ed

---------------------------------------------------------------- 
Ed Vance              edv@macrolink.com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------