From: Al Viro <viro@zeniv.linux.org.uk>
To: Maxime Ripard <mripard@redhat.com>
Cc: metux <metux@gmx.de>, "Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
"Christian König" <christian.koenig@amd.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: Requirements to merge new heaps in the kernel
Date: Thu, 31 Oct 2024 17:02:04 +0000 [thread overview]
Message-ID: <20241031170204.GL1350452@ZenIV> (raw)
In-Reply-To: <20241031-bouncy-cute-shrimp-cd2530@houat>
On Thu, Oct 31, 2024 at 05:45:23PM +0100, Maxime Ripard wrote:
> On Wed, Oct 30, 2024 at 12:16:22PM +0100, metux wrote:
> > On 22.10.24 10:38, Maxime Ripard wrote:
> > > I'm still interested in merging a carve-out driver[1], since it seems to be
> > > in every vendor BSP and got asked again last week.
> > >
> > > I remember from our discussion that for new heap types to be merged, we
> > > needed a kernel use-case. Looking back, I'm not entirely sure how one
> > > can provide that given that heaps are essentially facilities for
> > > user-space.
> >
> > For those who didn't follow your work, could you please give a short
> > intro what's that all about ?
> >
> > If I understand you correctly, you'd like the infrastructure of
> > kmalloc() et al for things / memory regions that aren't the usual heap,
> > right ?
>
> No, not really. The discussion is about dma-buf heaps. They allow to
> allocate buffers suitable for DMA from userspace. It might or might not
> from the system memory, at the heap driver discretion.
I'm afraid you've misinterpreted that - our hexapedal friend had just
* noticed that excessive crossposting can get it banned
* got itself a new address
* posted a solitary ping as the first test
* followed that by testing the ability to cross-post (posting you'd
been replying to, contents on chatGPT level)
* proceeded to use its shiny new address for more of the chorus
whinge exercise they'd been holding with several other similar fellows
(or sock puppets, for all I know).
Just ignore the wanker - it wasn't trying to get any information other
than "will the posting get through" anyway.
prev parent reply other threads:[~2024-10-31 17:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 8:38 Requirements to merge new heaps in the kernel Maxime Ripard
2024-10-22 16:19 ` John Stultz
2024-10-22 17:58 ` Nicolas Dufresne
2024-10-24 12:43 ` Maxime Ripard
2024-10-24 12:39 ` Maxime Ripard
2024-10-30 11:16 ` metux
2024-10-31 16:45 ` Maxime Ripard
2024-10-31 17:02 ` Al Viro [this message]
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=20241031170204.GL1350452@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=Brian.Starkey@arm.com \
--cc=benjamin.gaignard@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jstultz@google.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=metux@gmx.de \
--cc=mripard@redhat.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.