From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 26062CD4F25 for ; Sat, 16 May 2026 11:38:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 7BBE910E1AC; Sat, 16 May 2026 11:38:48 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (1024-bit key; unprotected) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="e4bYTYQ1"; dkim-atps=neutral Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by gabe.freedesktop.org (Postfix) with ESMTPS id 9262410E1AC; Sat, 16 May 2026 11:38:47 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 6B7B343BC2; Sat, 16 May 2026 11:38:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C8AA8C19425; Sat, 16 May 2026 11:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1778931527; bh=H8mAOeWk44Og/4ED7nEp6u4We/tCu4LArRG+KtxZ93k=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=e4bYTYQ1IFzOyGzcyeZWMrAiPpnmyMYcSLRQQi95dm+iq76V/XKOTcaYNXgLfmw1k 6nWDho9fq4Y/BNEYASWVYokzVul0kp7foBRtyJAjvkXtBm+yAgA0mKMk4foDvBZ7zp AWJnKP6k4OqUtaYUH7/b14TYFm1903wG8+eCD/RA= Date: Sat, 16 May 2026 13:38:51 +0200 From: Greg Kroah-Hartman To: Julian Orth Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , Christian =?iso-8859-1?Q?K=F6nig?= , Jonathan Corbet , Shuah Khan , Arnd Bergmann , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, linux-doc@vger.kernel.org, wayland-devel@lists.freedesktop.org Subject: Re: [PATCH 12/12] misc/syncobj: add new device Message-ID: <2026051652-pork-omission-b762@gregkh> References: <20260516-jorth-syncobj-v1-0-88ede9d98a81@gmail.com> <20260516-jorth-syncobj-v1-12-88ede9d98a81@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260516-jorth-syncobj-v1-12-88ede9d98a81@gmail.com> X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" 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 > --- > 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? Just curious, not a criticism of this in C at all. thanks, greg k-h