On Sat, May 16, 2026 at 1:38 PM Greg Kroah-Hartman <[email protected]> wrote: > > On Sat, May 16, 2026 at 01:06:15PM +0200, Julian Orth wrote: > > This device makes the DRM_IOCTL_SYNCOBJ_* ioctls available via a > > dedicated device. This allows applications to use syncobjs without > > having to open device nodes in /dev/dri, on systems that don't have any > > such nodes, or on systems whose devices don't support the > > DRIVER_SYNCOBJ_TIMELINE feature. > > > > Wayland uses syncobjs as its buffer synchronization mechanism. Most > > compositors use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to perform a pure > > CPU wait for syncobj point. DRM devices are not involved in this process > > except insofar that a DRM device needs to be used to access the ioctl. > > > > Similarly, a software-rendered client might perform rendering on a > > dedicated thread and use the wayland syncobj protocol to submit frames > > before they finish rendering. Again, this does not involve DRM devices > > except insofar ... as above. > > > > As an added benefit, this device removes the need to translate between > > file descriptors and handles. > > > > Signed-off-by: Julian Orth <[email protected]> > > --- > > Documentation/userspace-api/ioctl/ioctl-number.rst | 1 + > > drivers/misc/Kconfig | 10 + > > drivers/misc/Makefile | 1 + > > drivers/misc/syncobj.c | 404 > > +++++++++++++++++++++ > > include/uapi/linux/syncobj.h | 75 ++++ > > 5 files changed, 491 insertions(+) > > As this is a bunch of user-facing code, why not do this in rust to at > least get some semblance of proper parsing of user data sanity? Or is > the api to the drm layer just to complex for that at the moment?
I didn't consider using rust because I'm not familiar with rust in the kernel. But even if I had considered it, I probably would not have done it because drm_syncobj currently has no rust bindings. The driver as-is is just a thin layer around drm_syncobj.c so if drm_syncobj gains rust bindings it should be easy to convert the driver. > > Just curious, not a criticism of this in C at all. > > thanks, > > greg k-h
