Date: Wed, 21 Mar 2001 21:53:37 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: arch@FreeBSD.ORG Subject: Re: remind me again, why is MAXPHYS only 128k ? Message-ID: <Pine.LNX.4.21.0103212150360.13436-100000@zeppo.feral.com> In-Reply-To: <94011.985240101@critter>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 22 Mar 2001, Poul-Henning Kamp wrote: > In message <200103212224.f2LMOrh02530@mass.dis.org>, Mike Smith writes: > >> Another possibility for physio would be to MALLOC the pages > >> array at the very top level of the syscall and pass it down > >> through for use by lower layers. At the very top level, > >> before anything is locked, the MALLOC can block safely. > > > >This would deal with the async physio case too. > > > >I'm wondering how all this will interact with the general desire to avoid > >mapping an I/O request into linear KVM before handing it to a driver; I > >suspect probably not a lot... > > That is more dependent on fixing the device driver API than anything > else. Device driver API? The device driver API should be busdma, shouldn't it? The platform implementation for busdma can figure out what it needs to do- probably without any driver having to actually look at anything but the data direction flags for a bio, no? If a bio request describes a physical page list, busdma converts this into the appropriate tokens for the bus the device's dma engine is on. If the bio request describes KVM, then the platform busdma code finds the physical pages and does the same. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.21.0103212150360.13436-100000>