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

[Russell King]

On Sat, Jul 27, 2002 at 03:07:56PM -0700, Robert White wrote:
> I agree that that is what that line of the text says, my position is that
> the entire statement was was written nieavely, and proveably so.

Ok, so lets go through your claims.

> Throughout the entire section the standard (not the linux manual page)
> discusses "satisfying a read" (singular).

The text refers you, via a hyperlink to the read() function.  Which is
singular, because the interface is singular.  I fail to see what point
you're making here.

> The text was written with an
> "everybody will know basically what I mean" aditude that leaves it flawed
> for strict interpretation.

This sentence does not allow any misinterpretation:

   A pending read shall not be satisfied until MIN bytes are received
   (that is, the pending read shall block until MIN bytes are received),
   or a signal is received.

You call a read() on a blocking file descriptor.  It blocks until MIN bytes
are received.  End of story.  If you have MIN set to 10, and you've called
read(,,1), the pending read is blocked, for 1 byte and "shall block until
MIN bytes are received".  Crystal clear.

> And the linux manual pages still show through
> enough to use as the bases of my argument.

Who cares about the Linux manual pages when discussing a standard?  The
manual pages discuss an implementation of a standard that may very well
be buggy.  They are not a standard unto themselves.

As Alan Cox just confirmed to me - "Read SuSv3 , nothing else matters".

> Pre-Summary: My entire position rests on what the original author meant by 
> "receive".  That is, is it "receive into the driver" or "receive into the 
> user context".  He proveably meant receive into the user context (e.g. the 
> read buffer).

I disagree.  Firstly, this standard isn't describing your user space
program.  It's describing the behaviour of the read() system call with
respect to blocking.  Secondly, the third sentence of this paragraph
gives some insight into the purpose of VMIN:

  A program that uses case B to read record-based terminal I/O may block
  indefinitely in the read operation.

but that's only insight, and you can't hang too much on that.

> The best example to use for the "sloppyness" of writing in the standard and 
> manual page is that technically, if it is "receive into the driver", if you 
> have both VMIN and VTIME set non-zero, VTIME will not start until "a 
> character is received" which, by strict intrepertation of "received (by the 
> driver)", discounts the presence of any characters in the buffer.  Restated, 
> if it is "receive into the driver" this read will wait for a new character 
> even if there are hundreds of characters already buffered.

The standard covers that case:

  If data is in the buffer at the time of the read(), the result shall be
  as if data has been received immediately after the read().

So pre-existing data in the driver waiting to be read is treated as if
it were received _after_ you called read().  Which is sensible.

> (CITATION: from the linux manual page: "When both are set, a read will wait 
> until at least one character has been received, and then return  as  soon  as 
> either  MIN  characters  have been received or time TIME has passed since the 
> last character was received.")

The Linux manual page is not a standard.  It is therefore meaningless to
this discussion.

> [rest cut]

-- 
Russell King ([e-mail])                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html