From owner-cvs-all Sun Feb 1 05:18:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA06082 for cvs-all-outgoing; Sun, 1 Feb 1998 05:18:07 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from word.smith.net.au (ppp11.portal.net.au [202.12.71.111]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA06055; Sun, 1 Feb 1998 05:17:59 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id XAA05676; Sun, 1 Feb 1998 23:40:27 +1030 (CST) Message-Id: <199802011310.XAA05676@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: "Justin T. Gibbs" cc: Bruce Evans , 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 In-reply-to: Your message of "Thu, 29 Jan 1998 10:33:58 PDT." <199801291736.KAA09603@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 01 Feb 1998 23:40:26 +1030 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-To-Unsubscribe: mail to majordomo@FreeBSD.org "unsubscribe cvs-all" > >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. \\