Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sgi!shinobu!odin!sgihub!dragon!basie.wpd.sgi.com!des
From: des@basie.wpd.sgi.com (Des Young)
Newsgroups: comp.os.minix
Subject: Re: nice for Minix?
Message-ID: <1991Mar29.203312.14262@dragon.wpd.sgi.com>
Date: 29 Mar 91 20:33:12 GMT
References: <1991Mar20.221512.21591@vicstoy.UUCP> <1991Mar25.093908.13426@rtf.bt.co.uk> <go.670130351@jacobs.CS.ORST.EDU> <1991Mar28.064558.15562@bmerh408.bnr.ca>
Sender: news@dragon.wpd.sgi.com (CNews Account)
Reply-To: des@basie.wpd.sgi.com (Des Young)
Organization: Protocol Engines Inc., Mountain View, CA
Lines: 20

Hi,
  This is actually about multi-threaded FS. I agree with the previous
lines, it is a pity the FAQ sheet nips this stuff in the bud.
  I am working on a SCSI driver that supports streaming tape. The current
FS will never support it. You must have overlap in disk and tape I/O to
maintain streaming. This is such a standard requirement, no O/S can hold
its head up without tape support.
  The assumption I have made in my driver is at least that FS is capable of
supporting an outstanding I/O per task. This allows me to overlap wini, floppy,
tape and terminal I/O. It does complicate the driver a little (since wini,
floppy and tape all want to use the single SCSI bus). But this change to FS
seems much more reasonable than fully-fledged multi-threading. It also limits
the number of state-table entries in the driver (required for disconnect/
reconnect support).
  Now, I have not actually modified FS yet... :-), is anyone inspired ?
Cheers, Des.
-- 
trademarks abound, usual disclaimers apply, opinions are mine
des@pei.com	Des Young	(415) 335-1888
		Protocol Engines Inc., Mountain View, CA