On Tue, Sep 02, 2025 at 03:37:45PM -0700, John Stultz wrote: > On Tue, Sep 2, 2025 at 8:46 AM Thierry Reding <thierry.red...@gmail.com> > wrote: > > > > From: Thierry Reding <tred...@nvidia.com> > > > > Add a callback to struct dma_heap_ops that heap providers can implement > > to show information about the state of the heap in debugfs. A top-level > > directory named "dma_heap" is created in debugfs and individual files > > will be named after the heaps. > > > > I know its debugfs, but this feels a little loosey-goosey as an uAPI.
Well, the whole point of debugfs is that it's not really an ABI. Nothing should ever rely on the presence of these files. > Is there any expected format for the show function? > > What would other dmabuf heaps ideally export via this interface? I've thought about this a bit and I'm not sure it makes sense to standardize on this. I think on one hand having a list of buffers exported by the dma-buf heap is probably the lowest common denominator, but then there might be a bunch of other things that are very heap- specific that some heap might want to export. > Is there some consistent dma_heap-ish concept for it to justify it > being under a dma_heap directory, and not just an independent debugfs > file for the driver implementing the dmabuf heap? Well, I think just the fact that it's a dma-heap would qualify its corresponding debugfs to be in a well-known location. We could of course pick some arbitrary location, but that's just a recipe for chaos because then everybody puts these whereever they want. There's really no standard place for driver-specific debugfs files to go, so putting it into some "subsystem"-specific directory seems like the better option. Thierry
signature.asc
Description: PGP signature
