lkml.org 
[lkml]   [2002]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: n_tty.c driver patch (semantic and performance correction) (a ll recent versions)
Date
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. Throughout the
entire section the standard (not the linux manual page) discusses "satisfying
a read" (singular). The text was written with an "everybody will know
basically what I mean" aditude that leaves it flawed for strict
interpretation. And the linux manual pages still show through enough to use
as the bases of my argument.

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).

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.

(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.")

This "clearly states" that if you have a meg in the buffer (passed-tense
received) the driver "will wait for a character to be received" (imparative
future tense) but we all know that is dumb...

Even the existing implementation for VMIN and VTIME has them in the user read
context already, which is why the round-down is only the one compound
statement. That clearly shows that "received" is interpreted as "received
into the user context (read buffer)."

IF the context of "to receive", that is, the boundry between here and not-here
is fixed, by definition, to the read call itself, the technicalities all
disapear except one, that one being what to do if VMIN is greater than the
receive (read) buffer size since, in this more-consistent boundry point "to
receive" across, the more-than-buffer-sized characters can't ever then be
received by definition. The obvious interpretation is then not to wait for
the unreceivable characters.

There are more examples of the "received by" being the read call, and the
"received from" being the driver instead of the hardware. Look at when
non-raw processing take place.

Having only the raw-mode processing "receive" at the hardware level (with the
buffer tossed in halfway because we all know that's what it means 8-) doesn't
make consistent sense. Especially if it is to preserve a conception that
isn't ever used "in the wild".

Rob.


On Friday 26 July 2002 07:17, Russell King wrote:
> On Wed, Jun 26, 2002 at 10:48:30AM -0700, Ed Vance wrote:
> > 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.
>
> I just found this mail again. Yes, I agree with your interpretation,
> which reflects the code we presently have, as well as my reading of
> SuS. The SuS is quite clear that "A pending read shall not be
> satisfied until MIN bytes are received". It doesn't say "A pending
> read shall not be satisfied until MIN bytes or the number of requested
> bytes in read() are received"
>
> In addition, it also says "MIN represents the minimum number of bytes
> that should be received when the read() function returns successfully."
> Successful completion for read() is defined as "Upon successful
> completion, read() shall return a non-negative integer indicating the
> number of bytes actually read."
>
> So, for _any_ read() to a terminal with MIN set, for this call to
> return data (ie, success) MIN bytes must have been received.
>
> (Note that the behaviour where the number of bytes > MIN seems to be
> a little vague, SuS just talks about "block the calling thread until
> _some_ data becomes available" for the blocking case.)
>
> I'd be interested to know if Ted agrees with my position here; he is
> the author of the tty code, and is presently looking at that area.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.078 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site