Date: Wed, 23 Dec 1998 08:25:05 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Dan Strick <dan@math.berkeley.edu> Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: /dev/nrsa0 file mark handling Message-ID: <Pine.LNX.4.04.9812230816120.10770-100000@feral-gw> In-Reply-To: <199812231012.CAA17288@math.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I just got through actually re-implementing the 2FM@EOD as quirks. In my opinion it is only required, and only should be used, for tape drives that cannot detect physical end of media (this is different from early warning detection). Quirks are sufficient for this case. > > While I am at it, I have another "request". The "sa" tape driver > still needs a "control" device or some other way of accessing the > driver without conflicting with current I/O activity in order to > discover device status via the MTIOCGET ioctl(). (An alternative to > a control device would be special interpretation of the O_NONBLOCK > open flag.) It would be nice if the "struct mtget" fields mt_fileno > and mt_blkno were implemented. It would be nice if there was another > field that indicated the nature of any tape operation in progress > (e.g. REW, FSF, WEOF, simple I/O). "control open" - Already on my list. "mt_fileno/mt_blkno" - I'm mulling that one. Yes, I think I will, but it'll take a lot of work because there are (now) a large number of conditions that invalidate and make completely unknown those relative positions (EOD, hard block locating). "current state" - Interesting notion. -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.LNX.4.04.9812230816120.10770-100000>