Date: Mon, 20 Dec 1999 23:29:26 -0800 (PST) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: jdp@polstra.com (John Polstra) Cc: mjacob@feral.com (Matthew Jacob), scsi@freebsd.org, phk@freebsd.org, syssgm@detir.qld.gov.au (Stephen McKay), grog@lemis.com (Greg Lehey), rb@gid.co.uk (Bob Bishop), rivers@dignus.com (Thomas David Rivers), joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), hf@Melog.DE (Hauke Fath) Subject: Re: filemarks? Message-ID: <199912210729.XAA45172@gndrsh.dnsmgr.net> In-Reply-To: <XFMail.991220223903.jdp@polstra.com> from John Polstra at "Dec 20, 1999 10:39:03 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> Matthew Jacob wrote:
>
> > A user application detects EARLY WARNING during writing by
> > getting a return from the write(2) system call of zero (zero
> > bytes were written). If the device open is the non-rewinding
> > tape device, the application may close and reopen it and
> > continue writing until physical end of medium
>
> I'm sorry, but this is not the Unix elegance we all know and love.
> You're twisting yourself into knots trying to fit a square peg into
> a round hole. End of media is a classic "exceptional condition" and
> it needs to be handled as such. It can't just be contorted into the
> existing API, which simply has no room for it. That's why until now
> there has been no standard Unix way to deal with end of media --
> because it doesn't fit into the constraints of the write(2) API.
The API has a perfectly acceptable and working mechanism to deal with
this.
RETURN VALUES
Upon successful completion the number of bytes which were written is re-
turned. Otherwise a -1 is returned and the global variable errno is set
to indicate the error.
We seem to have 3 cases when Early Warning is detected:
a) The write(2) completed, all data has been written to the tape. Here
by definition we should simply return nbytes, after all, nothing is
wrong at this point, all the data did make it onto the tape. The
driver layer should set a flag at this point noting that Early Warning
has been seen but not delivered to the consumer. This flag will be
delivered by c) below, since the driver layer knows not to try and
put any more data on the tape.
b) The write(2) was not completed, some bytes did make it to the tape.
If _some_ bytes made it we should return how many did and set the
Early Warning flag as in a). If no bytes made it we return 0, which
is a degenerative case, no quite covered by the definition of
RETURN VALUE but in wide usage.
c) The write(2) was not able to put any data on the tape. Return -1, NOSPC.
Whats wrong with this model?
> I say again that the most reasonable way in Unix to handle exceptional
> conditions is to raise a signal. That's what signals are for. I
IMHO, this is _not_ an exceptional condition, but a normal condition
handled by the normal system call return values. Geez lewezzz the
computer industry has been dealing with magtape and EOM for 40 years
this way. Most mainframe class stuff on EOM detection does a
BSR WEOF REW and asks for a new volume. It seems only in the unix
world we have a major problem in dealing with this simple thing.
Is that because we have been missing BSR from all our tape programs?
> disagree with your earlier statement that signals are hard to program.
> All you have to do in the signal handler is set a flag. The mainline
> code, when it sees the flag, will do whatever it would have done if
> the write() call had returned a short count under your proposal.
I agree that signals are not hard to handle, but they I disagree that
they are the way to handle EOM.
> > p.s.: and thanks for the positive discussion on this! Finally we may be
> > able to get somewhere ....
>
> I think this discussion needs to take place on -arch or -current if it
> is to carry any weight. There are people who care about this stuff
> and who have informed opinions who aren't being included. How about
> moving it to -arch?
Agree..
--
Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912210729.XAA45172>