Date: Sun, 5 Jul 1998 19:11:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: julian@whistle.com (Julian Elischer) Cc: hackers@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: block device on wst device. Message-ID: <199807051911.MAA26965@usr08.primenet.com> In-Reply-To: <Pine.BSF.3.95.980704135433.10069E-100000@current1.whistle.com> from "Julian Elischer" at Jul 4, 98 01:58:28 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> ther is a block interface to wst > > is this used by anyone? > does it work? > > I think the block interface should go away > as it doesn't really make much sense on tapes. > (same for wt.c) > > In effect it went a way some time ago for st.c I still see this as a problem, specifically for tape devices. I see the block device for tape drives capable of providing a kernel side buffer that is not statically allocated to a particular driver and which provides bufferring for streaming tape devices. The examples I can come up with where the user space write to the buffer should return immediately so that the user space program can read, and therefore overlap physical tape and disk I/O, are DAT devices and QIC-40/80/120/etc. devices. This is specifically relevent to the FT (QIC-40/etc.) devices because of there use of a (normally) non-FIFO-ed serial interface, to wit, the floppy controller. Some people will say "yeah, but no one with any sense uses those"; however, I could make the same argument against IDE on the same basis (specifically, number of tagged commands drives allow in their queues). For a destop machine, cheap is often good enough, and FT drives are certainly cheap. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807051911.MAA26965>