Date: Mon, 20 Dec 1999 23:17:29 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: John Polstra <jdp@polstra.com> Cc: scsi@freebsd.org, phk@freebsd.org, Stephen McKay <syssgm@detir.qld.gov.au>, Greg Lehey <grog@lemis.com>, Bob Bishop <rb@gid.co.uk>, Thomas David Rivers <rivers@dignus.com>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de>, Hauke Fath <hf@Melog.DE> Subject: Re: filemarks? Message-ID: <Pine.BSF.4.10.9912202312040.56276-100000@beppo.feral.com> In-Reply-To: <XFMail.991220223903.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 20 Dec 1999, John Polstra wrote: > 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 But it's not quite end of media- it's a warning that it's near. > 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. > > 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 > 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 didn't mean to say it was hard to program- just that it's more stuff to add, but maybe not so bad. > The use of a signal for this is no different in concept than many > other uses of signals. Think about SIGPIPE, SIGXFSZ, SIGXCPU, and > SIGURG, for example, and you'll see that they serve the same kind of > purpose. Umm- what's your suggestion as to which one to use and is it set to SIG_IGN by default? > > > 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? We could move it there. What I'm trying to see is if there's a consensus among the people who actually use tapes about this. This would be on the scsi alias. So far, I'd still like to hear from Greg and Rodney Grimes in particular (they were the most vehement when I raised this last time on -current). Then I'd move it to a more generic 'unix sniff test' forum again. -matt 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?Pine.BSF.4.10.9912202312040.56276-100000>