Re: [Intel-gfx] [PATCH 02/19] dma-buf-map: Add helper to initialize second map
From: Lucas De Marchi
Date: Thu Jan 27 2022 - 03:18:13 EST
On Thu, Jan 27, 2022 at 09:02:54AM +0100, Christian König wrote:
Am 27.01.22 um 08:57 schrieb Lucas De Marchi:
On Thu, Jan 27, 2022 at 08:27:11AM +0100, Christian König wrote:
Am 26.01.22 um 21:36 schrieb Lucas De Marchi:
When dma_buf_map struct is passed around, it's useful to be able to
initialize a second map that takes care of reading/writing to an offset
of the original map.
Add a helper that copies the struct and add the offset to the proper
address.
Well what you propose here can lead to all kind of problems and is
rather bad design as far as I can see.
The struct dma_buf_map is only to be filled in by the exporter and
should not be modified in this way by the importer.
humn... not sure if I was clear. There is no importer and exporter here.
Yeah, and exactly that's what I'm pointing out as problem here.
You are using the inter driver framework for something internal to the
driver. That is an absolutely clear NAK!
We could discuss that, but you guys are just sending around patches to
do this without any consensus that this is a good idea.
s/you guys/you/ if you have to blame anyone - I'm the only s-o-b in
these patches. I'm sending these to _build consensus_ on what may be a good
use for it showing a real problem it's helping to fix.
From its documentation:
* The type :c:type:`struct dma_buf_map <dma_buf_map>` and its helpers are
* actually independent from the dma-buf infrastructure. When sharing buffers
* among devices, drivers have to know the location of the memory to access
* the buffers in a safe way. :c:type:`struct dma_buf_map <dma_buf_map>`
* solves this problem for dma-buf and its users. If other drivers or
* sub-systems require similar functionality, the type could be generalized
* and moved to a more prominent header file.
if there is no consensus and a better alternative, I'm perfectly fine in
throwing it out and using the better approach.
Lucas De Marchi