Hi Maarten, On 14 December 2012 17:27, Maarten Lankhorst <m.b.lankho...@gmail.com>wrote:
> Op 14-12-12 10:36, sumit.sem...@ti.com schreef: > > From: Sumit Semwal <sumit.sem...@linaro.org> > > > > Add debugfs support to make it easier to print debug information > > about the dma-buf buffers. > > > I like the idea, I don't know if it could be done in a free manner, but > for bonus points > could we also have the dma-buf fd be obtainable that way from a debugfs > entry? > > Doing so would allow me to 'steal' a dma-buf from an existing mapping > easily, and test against that. Also I think the name of the device and process that exported the dma-buf > would be useful > to have as well, even if in case of the device that would mean changing > the api slightly to record it. > > I was thinking of having a directory structure like this: > > /sys/kernel/debug/dma_buf/stats > > and then for each dma-buf: > > /sys/kernel/debug/dma-buf/exporting_file.c/<number>-fd > /sys/kernel/debug/dma-buf/exporting_file.c/<number>-attachments > /sys/kernel/debug/dma-buf/exporting_file.c/<number>-info > > Opening the fd file would give you back the original fd, or fail with -EIO > if refcount was dropped to 0. > > Would something like this be doable? I don't know debugfs that well, but I > don't see why it wouldn't be, > Let me think more about it, but I am inclined to add simple support first, and then add more features to dma_buf debugfs as it grows. I still would want to take Daniel's suggestion on dma_buf_export_named() before I push this patch, so I guess I'll try to work a little more and prepare it for 3.9? I quite like your idea of .../dma-buf/<exporting_file.c>/... , which would need the above as well :) > > ~Maarten > > Best regards, ~Sumit.
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
