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 AADD1C6FD19 for ; Thu, 9 Mar 2023 20:24:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id ED79310E2A8; Thu, 9 Mar 2023 20:24:37 +0000 (UTC) Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3B0DD10E2A8 for ; Thu, 9 Mar 2023 20:24:36 +0000 (UTC) Received: from 2603-8080-2102-63d7-c4a8-7e10-0391-f3ff.res6.spectrum.com (2603-8080-2102-63d7-c4a8-7e10-0391-f3ff.res6.spectrum.com [IPv6:2603:8080:2102:63d7:c4a8:7e10:391:f3ff]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: gfxstrand) by madras.collabora.co.uk (Postfix) with ESMTPSA id 9E34F660301A; Thu, 9 Mar 2023 20:24:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1678393474; bh=iHVcle3qz6S4204P78xSSiIZLX3fAIlrxoRx24QoWEc=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Rm6Rb5jgc4KgSZ8CIfxw997YRUUmkZyouZw0049no8/knLpJh1cwuNXsK/1sjbIlq EV4GUg2aXqjzfFjkkvApU/rKcF1vgyQ1UmLeSCvTlrN1MkR79+4o+E1BMkgIGGCYLh /K/hvQHYHoJm8xfVcnW4szl1obTlHP0QloefieBQQYyOFF/uKmLwXQqPYeHqT+44Vl qRmbCLyJ7vApu05NcHSu020jX2svAQm3WaPzSQ34yW2qeyQsLNouNRX9l4f3zDxVlz XzdOH8rIvgBs+CecGqmP1IQURW8IhD+uxtTOll9MFa+N9QvhSHHNtCeki9Mw7Kx40K gVFSwyUGI5Y4g== Message-ID: Subject: Re: [PATCH RFC 01/18] rust: drm: ioctl: Add DRM ioctl abstraction From: Faith Ekstrand To: Asahi Lina , =?ISO-8859-1?Q?Bj=F6rn?= Roy Baron Date: Thu, 09 Mar 2023 14:24:25 -0600 In-Reply-To: <11ce9291-c17f-e73d-fb5d-13d5386fe6be@asahilina.net> References: <20230307-rust-drm-v1-0-917ff5bc80a8@asahilina.net> <20230307-rust-drm-v1-1-917ff5bc80a8@asahilina.net> <11ce9291-c17f-e73d-fb5d-13d5386fe6be@asahilina.net> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 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: , Cc: Karol Herbst , Dave Hansen , dri-devel@lists.freedesktop.org, Mary , Gary Guo , Ella Stanforth , Sumit Semwal , Alyssa Rosenzweig , Luben Tuikov , Alex Gaynor , Miguel Ojeda , linux-media@vger.kernel.org, Wedson Almeida Filho , rust-for-linux@vger.kernel.org, Boqun Feng , linaro-mm-sig@lists.linaro.org, linux-sgx@vger.kernel.org, linux-kernel@vger.kernel.org, Jarkko Sakkinen , asahi@lists.linux.dev, Thomas Zimmermann , Christian =?ISO-8859-1?Q?K=F6nig?= Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Thu, 2023-03-09 at 15:04 +0900, Asahi Lina wrote: > On 08/03/2023 02.34, Bj=C3=B6rn Roy Baron wrote: > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 // SAFETY: This is just the ioctl > > > argument, which hopefully has the right type > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 // (we've done our best checking the > > > size). > >=20 > > In the rust tree there is the ReadableFromBytes [1] trait which > > indicates that it is safe to read arbitrary bytes into the type. > > Maybe you could add it as bound on the argument type when it lands > > in rust-next? This way you can't end up with for example a struct > > containing a bool with the byte value 2, which is UB. >=20 > There's actually a much bigger story here, because that trait isn't > really very useful without a way to auto-derive it. I need the same > kind > of guarantee for all the GPU firmware structs... >=20 > There's one using only declarative macros [1] and one using proc > macros > [2]. And then, since ioctl arguments are declared in C UAPI header > files, we need a way to be able to derive those traits for them... > which > I guess means bindgen changes? It'd be cool to be able to auto-verify that uAPI structs are all tightly packed and use the right subset of types. Maybe not possible this iteration but it'd be cool to see in future. I'd like to see it for C as well, ideally. ~Faith