On Thursday, June 2nd, 2022 at 07:40, Greg KH greg@kroah.com wrote:
On Wed, Jun 01, 2022 at 04:13:14PM +0000, Simon Ser wrote:
To discover support for new DMA-BUF IOCTLs, user-space has no choice but to try to perform the IOCTL on an existing DMA-BUF.
Which is correct and how all kernel features work (sorry I missed the main goal of this patch earlier and focused only on the sysfs stuff).
However, user-space may want to figure out whether or not the IOCTL is available before it has a DMA-BUF at hand, e.g. at initialization time in a Wayland compositor.
Why not just do the ioctl in a test way? That's how we determine kernel features, we do not poke around in sysfs to determine what is, or is not, present at runtime.
Add a /sys/kernel/dmabuf/caps directory which allows the DMA-BUF subsystem to advertise supported features. Add a sync_file_import_export entry which indicates that importing and exporting sync_files from/to DMA-BUFs is supported.
No, sorry, this is not a sustainable thing to do for all kernel features over time. Please just do the ioctl and go from there. sysfs is not for advertising what is and is not enabled/present in a kernel with regards to functionality or capabilities of the system.
If sysfs were to export this type of thing, it would have to do it for everything, not just some random tiny thing of one kernel driver.
I'd argue that DMA-BUF is a special case here.
To check whether the import/export IOCTLs are available, user-space needs a DMA-BUF to try to perform the IOCTL. To get a DMA-BUF, user-space needs to enumerate GPUs, pick one at random, load GBM or Vulkan, use that heavy-weight API to allocate a "fake" buffer on the GPU, export that buffer into a DMA-BUF, try the IOCTL, then teardown all of this. There is no other way.
This sounds like a roundabout way to answer the simple question "is the IOCTL available?". Do you have another suggestion to address this problem?