Date: Sun, 01 Feb 1998 23:40:26 +1030 From: Mike Smith <mike@smith.net.au> To: "Justin T. Gibbs" <gibbs@plutotech.com> Cc: Bruce Evans <bde@zeta.org.au>, toor@dyson.iquest.net, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, mike@smith.net.au Subject: Re: cvs commit: src/sys/i386/isa wfd.c Message-ID: <199802011310.XAA05676@word.smith.net.au> In-Reply-To: Your message of "Thu, 29 Jan 1998 10:33:58 PDT." <199801291736.KAA09603@pluto.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> >I think a function call bdevswp->d_maxio() would be efficient enough. > >You copy the value the vnode on open and always access it from there. > >At least if the vnode remains bloated with v_maxio. > > > >There should also be a cdevsw function to give the "best" i/o size. > > Exactly. This was mostly what John and I talked about. I think > a single function call that returns the "maximum efficient" i/o size and > the "maximum possible" I/O size along with some information to indicate > any alignment constraints on those values is better than adding > more functions for each piece of information. Right now the "best" and > the "max" are the same, but if I can ever get back to adding code > to consolidate large transfers in the bus dma code, we should be able to > handle things like large tape blocks even on controllers that support > relatively few SG elements. I can think of quite a few more things that would be useful to extract in a generalised fashion. (eg. idle timeouts, max queue length, &c.) You hinted that CAM offers a mechanism for this sort of extraction; can we standardise on something like that & perhaps mutate it back onto the legacy drivers? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802011310.XAA05676>