From owner-freebsd-scsi Mon Dec 20 23:29:45 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2AB1A14E94; Mon, 20 Dec 1999 23:29:38 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA45172; Mon, 20 Dec 1999 23:29:26 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199912210729.XAA45172@gndrsh.dnsmgr.net> Subject: Re: filemarks? In-Reply-To: from John Polstra at "Dec 20, 1999 10:39:03 pm" To: jdp@polstra.com (John Polstra) Date: Mon, 20 Dec 1999 23:29:26 -0800 (PST) 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) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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