On 12/06/2024 22:52, Laurent Pinchart wrote: > Hi Mauro, > > 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. 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, Hans
