From owner-svn-src-all@FreeBSD.ORG Tue May 12 21:28:15 2009 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF8C1065673; Tue, 12 May 2009 21:28:15 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4438FC08; Tue, 12 May 2009 21:28:14 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n4CLSDtJ052222; Tue, 12 May 2009 23:28:13 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n4CLSDj7052221; Tue, 12 May 2009 23:28:13 +0200 (CEST) (envelope-from marius) Date: Tue, 12 May 2009 23:28:13 +0200 From: Marius Strobl To: Robert Noland Message-ID: <20090512212813.GF1158@alchemy.franken.de> References: <200905122056.n4CKuYpZ032804@svn.freebsd.org> <1242162786.1755.51.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1242162786.1755.51.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r192026 - head/share/man/man9 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 21:28:16 -0000 On Tue, May 12, 2009 at 04:13:06PM -0500, Robert Noland wrote: > On Tue, 2009-05-12 at 20:56 +0000, Marius Strobl wrote: > > Author: marius > > Date: Tue May 12 20:56:34 2009 > > New Revision: 192026 > > URL: http://svn.freebsd.org/changeset/base/192026 > > > > Log: > > Correct r190283 (partially reverting it) as on sparc64 BUS_DMA_NOCACHE > > actually is only valid for bus_dmamap_load(). > > Ok, this is getting very confusing... This means that code has to set > this flag on both alloc and load to allow for somethine resembling > consistent behavior. > Personally I don't understand why amd64 and i386 where decided to implement BUS_DMA_NOCACHE for bus_dmamem_alloc(9) only as this is less flexible than using it with bus_dmamap_load(9) (which also is the older existing implementation). Anyway, documents BUS_DMA_NOCACHE and BUS_DMA_NOWRITE as "non-standard or specific to only certain architectures" so I think it's okay for the usage of these flags to differ across them. Marius