From: "Christian König" <christian.koenig@amd.com>
To: Bastien Curutchet <bastien.curutchet@bootlin.com>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses.
Date: Fri, 11 Apr 2025 14:41:56 +0200 [thread overview]
Message-ID: <45bbee88-0446-4773-a4b6-d19a1747c43f@amd.com> (raw)
In-Reply-To: <60e2d844-418a-4bde-b6ef-76d10448d5ec@bootlin.com>
Hi Bastien,
Am 11.04.25 um 10:14 schrieb Bastien Curutchet:
> Hi Christian,
>
> On 4/11/25 9:30 AM, Christian König wrote:
>> Hi Thomas,
>>
>> Am 10.04.25 um 21:43 schrieb Thomas Petazzoni:
>>> Hello Christian,
>>>
>>> Thanks for your feedback!
>>>
>>> On Thu, 10 Apr 2025 18:29:12 +0200
>>> Christian König<christian.koenig@amd.com> wrote:
>>>
>>>>> Many UIO users performing DMA from their UIO device need to access the
>>>>> DMA addresses of the allocated buffers. There are out-of-tree drivers
>>>>> that allow to do it but nothing in the mainline.
>>>> Well that basically disqualifies this patch set in the first paragraph.
>>>>
>>>> To justify some kernel change we always need an in kernel user of the
>>>> interface, since this is purely for out-of-tree drivers this is a
>>>> no-go to begin with.
>>> I'm not sure to understand your comment here. This patch series is
>>> about extending the UIO interface... which is a user-space interface.
>>> So obviously it has no "in-kernel user" because it's meant to be used
>>> from user-space. Could you clarify what you meant here?
>>
>> Bastien wrote about "out-of-tree drivers" which is something the upstream kernel explicitly does not support.
>>
>
> Sorry maybe it wasn't clear, but what I meant is that the goal of this series is to replace 'out-of-tree drivers' with something upstream.
Ah! Yeah that wasn't really clear from the description.
But anyway please note that when you want to create new UAPI you need to provide an open source user of it. E.g. link to a repository or something similar in the covert letter should do it.
>> Well why do you then want to use DMA-buf in the first place? As far as I know what you describe can perfectly be done with the normal UIO memory management interfaces.
>>
>> DMA-buf is only interesting when you actually want to share something in between devices or between applications.
>>
>
> I wanted to use DMA-buf because it allows to dynamically allocate/release coherent buffers from userspace. UIO doesn't provide such interface.
> I'm aware that exposing DMA addresses to userspace isn't a good practice. That's why this series create a new heap specific to UIO that will be the only one implementing the new ioctl.
I don't know the UIO interfaces that well, but that is pretty clearly an abuse of DMA-buf and won't fly at all.
If you want coherent memory for your device you should use dma_alloc_coherent() for that.
Regards,
Christian.
>
>
> Best regards,
> Bastien
>
>
>
next prev parent reply other threads:[~2025-04-11 12:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-10 14:53 [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses Bastien Curutchet
2025-04-10 14:53 ` [PATCH 1/3] dma-buf: Allow heap that doesn't provide map_buf/unmap_buf Bastien Curutchet
2025-04-10 14:53 ` [PATCH 2/3] dma-buf: Add DMA_BUF_IOCTL_GET_DMA_ADDR Bastien Curutchet
2025-04-11 18:34 ` Nicolas Dufresne
2025-04-29 6:39 ` Simona Vetter
2025-04-29 8:12 ` Christian König
2025-04-10 14:53 ` [PATCH 3/3] uio: Add UIO_DMABUF_HEAP Bastien Curutchet
2025-04-11 18:41 ` Nicolas Dufresne
2025-04-10 16:29 ` [PATCH 0/3] uio/dma-buf: Give UIO users access to DMA addresses Christian König
2025-04-10 19:43 ` Thomas Petazzoni
[not found] ` <b596c9af-c0e3-4557-b45a-462a33179235@amd.com>
2025-04-11 8:14 ` Bastien Curutchet
2025-04-11 12:41 ` Christian König [this message]
2025-04-14 8:17 ` Thomas Petazzoni
2025-04-14 8:59 ` Christian König
2025-04-14 5:55 ` Christoph Hellwig
2025-04-14 8:24 ` Thomas Petazzoni
2025-04-14 9:11 ` Christian König
2025-04-14 11:52 ` Thomas Petazzoni
2025-04-14 11:24 ` Christoph Hellwig
2025-04-14 11:48 ` Thomas Petazzoni
2025-04-14 17:08 ` Andrew Davis
2025-04-14 19:21 ` Thomas Petazzoni
2025-04-14 20:13 ` Andrew Davis
2025-04-22 18:16 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45bbee88-0446-4773-a4b6-d19a1747c43f@amd.com \
--to=christian.koenig@amd.com \
--cc=bastien.curutchet@bootlin.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox