linux-kernel - Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1199809628.3534.34.camel@localhost.localdomain>
Date:	Tue, 08 Jan 2008 10:27:08 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	akepner@....com
Cc:	Tony Luck <tony.luck@...el.com>,
	Grant Grundler <grundler@...isc-linux.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Jes Sorensen <jes@....com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Roland Dreier <rdreier@...co.com>,
	David Miller <davem@...emloft.net>,
	Muli Ben-Yehuda <muli@...ibm.com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC/PARTIAL PATCH 0/3] dma: passing "attributes" to dma_map_*
	routines

On Mon, 2008-01-07 at 21:32 -0500, akepner@....com wrote:
>         The following patchset allows additional "attributes" to be 
>         passed to dma_map_*/dma_unmap_* implementations. (The reason 
>         why this is useful/necessary has been mentioned several
>         times, 
>         most recently here:
>         http://marc.info/?l=linux-kernel&m=119258541412724&w=2.)
>         
>         This is incomplete in that only ia64 and x86_64 are supported
>         - 
>         the purpose is mainly to give us something specific to
>         discuss. 

I'm already on record saying I don't think attributes in the generic
code is the right approach.  All of the attributes I can see adding are
bus specific (even to the extent that PCIe ones wouldn't apply to PCI
for instance).  I really think the right approach is to sort out the
attribute infrastructure and not try to overload the generic DMA API.  I
can certainly see that we might like to use it to take advantage of
other PCIe attributes (where available, of course).

Ultimately, it might be the best implementation course to pass the
attributes in to the dma_map routines, but I can't see them being
generic, they'd still be bus specific, so the correct way is to have a
bus specific attribute setup routine and pass some sort of opaque
attribute handle (or even just use the existing dma handle).

>         The approach here is to change the dma_map_* interface so 
>         that the last argument is an u32 which encodes the direction 
>         of the dma and, optionally, other attributes. Changing the 
>         interface is a bit intrusive, but callers of dma_map_* don't 
>         need to be modified.
>         
>         There are 3 patches:
>         
>         [1/3] dma: create linux/dma-direction.h 
>         [2/3] dma: ia64/sn2 allow "attributes" to be used by dma_map_*
>         [2/3] dma: x86_64 allow "attributes" to be used by dma_map_*

James

P.S. please update my email address: the @steeleye.com one no longer
works now.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/