On Fri, Dec 14, 2012 at 5:57 AM, Maarten Lankhorst <m.b.lankhorst@xxxxxxxxx> wrote: > Op 14-12-12 10:36, sumit.semwal@xxxxxx schreef: >> From: Sumit Semwal <sumit.semwal@xxxxxxxxxx> >> >> 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, yeah.. but sort of back-door's the security benefits of an anonymous fd.. BR, -R > ~Maarten > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
