Date: Wed, 22 Sep 1999 14:08:55 -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.9909221405200.581-100000@semuta.feral.com> In-Reply-To: <35734.938034230@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 22 Sep 1999, Poul-Henning Kamp wrote: > In message <Pine.BSF.4.05.9909221352030.581-100000@semuta.feral.com>, Matthew J > acob writes: > >> > >> >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". > > We already have flags to disable read and write clustering: > > #define D_NOCLUSTERR 0x10000 /* disables cluter read */ > #define D_NOCLUSTERW 0x20000 /* disables cluster write */ > #define D_NOCLUSTERRW (D_NOCLUSTERR | D_NOCLUSTERW) > > but again: per device driver, not per device. > > We don't actually use it anymore, it was only used by vn.c, now it > just clutters up about 50 lines of source code all over the place. > > Anyone has good reasons why we should keep these flags ? Oops- should have checked. I'm thinking that device drivers may want to inform the system of certain device properties, but until this is thought out more clearly, maybe we shouldn't bother and just stick to provisioning for known issues (like MAXPHYS which I still think should be a variable, or a config option and fix loadable modules to not use compile time constants- which they shouldn't be doing anyhow> > > >> >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... :-) > > "bytes" :-) Yeah, but how many? If we should ever port FreeBSD to the PDP-11, 'int' will be only 16 bits ... :-) 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.9909221405200.581-100000>