On Thu, Jun 13, 2024 at 11:38:47AM +0200, Hans Verkuil wrote: > On 13/06/2024 11:12, Laurent Pinchart wrote: > > On Thu, Jun 13, 2024 at 09:08:55AM +0200, Hans Verkuil wrote: > >> On 12/06/2024 22:52, Laurent Pinchart wrote: > >>> On Wed, Jun 12, 2024 at 10:44:06PM +0200, Mauro Carvalho Chehab wrote: > >>>> Em Wed, 12 Jun 2024 11:34:30 +0300 Laurent Pinchart escreveu: > >>>> > >>>>> Focussing on this topic, if we're brainstorming memory management for > >>>>> media devices, I'd like to throw in a controversial idea. In addition to > >>>>> being clearer on the fact that USERPTR is deprecated, I would like to > >>>>> deprecate MMAP too and only focus on DMABUF. I believe Linux needs a > >>>>> centralized buffer allocator, instead of having multiple allocation APIs > >>>>> scattered in different places. There are design ideas in gralloc that we > >>>>> could benefit from. > >>>> > >>>> Deprecating USERPTR is doable, as not many apps use it, and they're > >>>> mostly focused on complex camera/ARM scenario. Now, deprecating MMAP at > >>>> V4L2 core is a different history: lots of different userspace programs, > >>>> including browsers and proprietary apps like zoom, etc. rely on MMAP > >>>> support. We can only consider deprecating MMAP once applications switch > >>>> to DMABUF. > >>> > >>> Deprecating doesn't mean dropping it right away, it means telling > >>> application developers that DMABUF is the recommended way. We will still > >>> have to support MMAP for a long time, including fixing bugs in it, as > >>> that will be a long transition. And it first requires solving the > >>> problem of centralizing allocation for DMABUF. It won't happen > >>> overnight, but I'm trying to gather support for the idea, and get people > >>> to collaborate on solving the technical problems that are currently > >>> blocking this long term evolution. If the media subsystem endorsed the > >>> effort, basically saying publicly that we are fine deprecating MMAP in > >>> principle once a good replacement will be available, it may help. I > >>> don't expect the deprecation to happen before at least two years, and > >>> the removal from the kernel would probably take another 10 to 15 years > >>> :-) > >> > >> IMHO you cannot removed MMAP support: it is the only streaming I/O method > >> that is supported by all drivers, whereas DMABUF isn't. And many, many userspace > >> applications use that. Nor does it pose problems: it just works. > > > > I may have failed to get my point across properly, so I'll try again :-) > > > > What I would like to do is > > > > 1. Explore how we can implement a centralized allocator that > > applications can use on any Linux system to provide dmabuf instances. > > Would be nice. > > > 2. Implement that allocator. > > Good. > > 2.5: start adding DMABUF support to all drivers that do not yet > support this. > > > 3. Deprecate MMAP, meaning documenting that users of V4L2 should use the > > centralized allocator and DMABUF. No code change in V4L2, no removal of > > MMAP, and bugs in MMAP support would keep being addressed. > > > > 4. 5-10 years later, start scheduling MMAP removal, as in setting a date > > for it. > > > > 5. 5-10 years more in the future, drop MMAP when nobody will be using it > > anymore. > > 3-5: seems pointless to me. It would break many userspace applications. > > Frankly, MMAP just works, and has since forever. Perhaps at some point > we might switch to dmabufs internally to vb2 (that would require that > the driver can call that central allocator!) if that would simplify > matters, but in the uAPI we need to keep MMAP. 3 is important in my opinion, it's about telling, once 1-2 are in place, that new applications should use the new API. It doesn't break anything because it doesn't change any code in the kernel. The only thing that will change is the V4L2 documentation, to tell users "please use DMABUF for new applications". Nothing more than that. 4-5 are not strictly necessary, and are for much later anyway. They're about dropping a feature once all users will be gone. If it happens, it won't break anything because nobody will notice :-) > > It's phases 1 to 3 that I'm the most interested in. 4 and 5 are just > > about dropping code *when* MMAP isn't used anymore *iff* that ever > > happens. > > > >> USERPTR support is another matter: there have been problems with it, and > >> the vb2 code is hard to understand and to support. > >> > >> I wouldn't shed a tear if it disappears. The strategy would be to first > >> make sure any driver supporting USERPTR also supports DMABUF, and then > >> put USERPTR under a kernel config option. Initially it would default to y, > >> but issue a warning, and later (after a few years) it can default to n > >> and eventually be removed. -- Regards, Laurent Pinchart
