On Thursday, June 2nd, 2022 at 07:40, Greg KH <greg@xxxxxxxxx> 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?
