On Mon, Jun 3, 2024 at 4:40 AM <hailong.liu@xxxxxxxx> wrote: > > From: "Hailong.Liu" <hailong.liu@xxxxxxxx> > > This help module use heap_flags to determine the type of dma-buf, > so that some mechanisms can be used to speed up allocation, such as > memory_pool, to optimize the allocation time of dma-buf. This feels like it's trying to introduce heap specific flags, but doesn't introduce any details about what those flags might be? This seems like it would re-allow the old opaque vendor specific heap flags that we saw in the ION days, which was problematic as different userspaces would use the same interface with potentially colliding heap flags with different meanings. Resulting in no way to properly move to an upstream solution. With the dma-heaps interface, we're trying to make sure it is well defined. One can register a number of heaps with different behaviors, and the heap name is used to differentiate the behavior. Any flags introduced will need to be well defined and behaviorally consistent between heaps. That way when an upstream solution lands, if necessary we can provide backwards compatibility via symlinks. So I don't think this is a good direction to go for dma-heaps. It would be better if you were able to clarify what flag requirements you need, so we can better understand how they might apply to other heaps, and see if it was something we would want to define as a flag (see the discussion here for similar thoughts: https://lore.kernel.org/lkml/CANDhNCoOKwtpstFE2VDcUvzdXUWkZ-Zx+fz6xrdPWTyciVXMXQ@xxxxxxxxxxxxxx/ ) But if your vendor heap really needs some sort of flags argument that you can't generalize, you can always implement your own dmabuf exporter driver with whatever ioctl interface you'd prefer. thanks -john
