Date: Wed, 22 Sep 1999 13:54:10 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> 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 Message-ID: <Pine.BSF.4.05.9909221352030.581-100000@semuta.feral.com> In-Reply-To: <35615.938033333@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> > >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9909221352030.581-100000>