[SNIP]
Why is this patch a hack? We found a problem with the initial designPerhaps we should go just one step further and make a misc device nodeYeah, totally agree on the complexity note. I'm just absolutely not keen
for dmabug debugging information to be in and just have userspace
poll/read on the device node and we spit the info that used to be in
debugfs out through that? That way this only affects systems when they
want to read the information and not normal code paths? Yeah that's a
hack, but this whole thing feels overly complex now.
to add hack over hack over hack to make something work which from my
point of view has some serious issues with it's design.
which nobody saw when it was originally created, and now we're trying
to address it within the constraints that exist.
Is there some other
solution to the problem of exports getting blocked that you would
suggest here?
For example trying to do accounting based on DMA-bufs is extremelyThe use case was described in the commit message when the feature was
questionable to begin with. See a modern game for example can have
between 10k and 100k of different buffers, reserving one file descriptor
for each of those objects is absolutely not going to work.
So my request is to please describe your full use case and not just why
you think this patch is justified.
initially added (after discussion about it on the list) including
links to code that uses the feature:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20210603214758.2955251-1-hridya%40google.com%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C3f6e3e98fc6f45ead80d08da385a59e6%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637884257979664387%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=i%2BSfpB%2B6iBolBHu6KrKH3njq0zo1SBbrKDHZOjpsIks%3D&reserved=0
Regards,
Christian.
thanks,
greg k-h