From owner-cvs-all Wed Sep 22 13:54:48 1999 Delivered-To: cvs-all@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A4BF15CE7; Wed, 22 Sep 1999 13:54:15 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.8.7/8.8.7) with ESMTP id NAA02465; Wed, 22 Sep 1999 13:52:29 -0700 Date: Wed, 22 Sep 1999 13:54:10 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_physio.c src/sys/miscfs/specfs spec_vnops.c src/sys/sys conf.h In-Reply-To: <35615.938033333@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > >Should si_iosize_max be cognizant of all limitations (e.g., HBA DMA > >limitations)? > >.. > > The right description of this field really might be "a transaction > larger than this size cannot be carried out in one operation, so > don't bother clustering more than that." Yes, that's what I was looking for. It'd be nice to have flags too, I suppose, that allow the device driver to say "don't prefetch". > >Can si_iosize_max be a sized integer? > > If by this you mean that it should be number of DEV_BSIZE sectors the > answer is no, there is/should be nothing which limit us to sectors > of DEV_BSIZE (think audio CDs). I don't think a transaction size > limit of ~1GB is going to be a limitation in the near future. Naw, I was just being picky- all things that declare a size should be specific about the size... :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message