Date: Mon, 20 Dec 1999 22:39:03 -0800 (PST) From: John Polstra <jdp@polstra.com> To: Matthew Jacob <mjacob@feral.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: <XFMail.991220223903.jdp@polstra.com> In-Reply-To: <Pine.BSF.4.05.9912200924410.32761-100000@semuta.feral.com>
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. 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. 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. > 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? John 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?XFMail.991220223903.jdp>