Subject: Re: (2nd send) opinion sought about EOM handling for tapes
To: Todd Whitesel <toddpw@best.com>
From: Matthew Jacob <mjacob@feral.com>
List: tech-kern
Date: 07/13/1998 23:48:18
On Mon, 13 Jul 1998, Todd Whitesel wrote:

> > The only trick here is that you may get, in the driver, EARLY WARNING
> > but still have satisfied the I/O request completely. In this case, the
> > driver has to maintain state so that the *next* write gets a (synthesized
> > and immediate) 'short' write (with a value returned such that the
> > application believes (correctly) that no data was moved for this I/O
> > operation).
> 
> Okay, but unless I'm missing something, that means a synthesized return of
> exactly zero. This seems (to me) to conflict with your earlier statement
> that the driver would guarantee a "non-zero residual" since I have been
> reading that as implying a "short write" returning something between zero
> and the request count.
> 
> Admittedly I came into this thread late, but I thought I smelled an API
> leak in your proposal -- an ambiguity when the correct value to return is
> a "short write" of exactly zero.
> 

Return to whom of 'zero'? The write(2) system call will report
that it moved zero bytes (will return 0). That is less than
the amount requested (presumably), but greater than -1 (indication
to check errno). Seems like standard UNIX EOF semantics to me.
It's also true that a return value of N-1 (where N is the amount
requested in the write(2) call) is also "EOF" semantics as well.

Am I being too dense here?  Can someone else who is reading this
help us out here?