From owner-freebsd-arch@FreeBSD.ORG Fri Jan 30 14:56:28 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B9053790 for ; Fri, 30 Jan 2015 14:56:28 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71EDA6AB for ; Fri, 30 Jan 2015 14:56:28 +0000 (UTC) Received: from new-host-3.home (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6710CB913; Fri, 30 Jan 2015 09:56:27 -0500 (EST) Message-ID: <54CB9B9F.50905@FreeBSD.org> Date: Fri, 30 Jan 2015 09:56:31 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Poul-Henning Kamp Subject: Re: Wrapper API for static bus_dma allocations References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <67604.1422568494@critter.freebsd.dk> In-Reply-To: <67604.1422568494@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 30 Jan 2015 09:56:27 -0500 (EST) Cc: 'freebsd-arch' X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 14:56:28 -0000 On 1/29/15 4:54 PM, Poul-Henning Kamp wrote: > -------- > In message <2800970.jY4xzTy9Hz@ralph.baldwin.cx>, John Baldwin writes: > >> The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for >> descriptor rings) can be a bit obtuse [...] > > Isn't it time we take a good hard stare at all of the bus_dma API, > and refactor it into something a lot more compact ? Given the amount of oddball hardware out there I don't think there is a lot you can cut out. The filter function might be something we can lose (and losing it would simplify the implementation), but all the other weird constraints are actually used by something AFAIK. I do think we can provide some simpler wrappers for some of the more common cases, but there will be some hardware for which those wrappers do not work. One suggestion Scott has had is to at least make it easier to extend the API by using getter/setter routines on the tag to work with tag attributes instead of passing them all in bus_dma_tag_create(). -- John Baldwin