From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fout-a4-smtp.messagingengine.com (fout-a4-smtp.messagingengine.com [103.168.172.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C0861D0DDA; Wed, 2 Oct 2024 15:45:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.147 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727883937; cv=none; b=Ewbx+QTT1TQ4Kk6ElBqdvp4MarrTHAaAxrc1hG7FiVImaLTRHOxuYY1c6KP7KEv4gVFaySoe+MxanxSQb+NTLIemJMNkB+nevblWZkWMgrWIUhjvjfw3hIX472lfPrHzP8Ion7J+uNTmezOO9E6o0bsUayFoCtXK8bVTV1UOX8M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1727883937; c=relaxed/simple; bh=eNw4arMQ67mFk/jMxU41QXu7mkTh6QRJeAtFMw5V9fA=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=J5TRjMPZEHrw01zDXB3GsBVPz3V++idbQFrAlLjkRPBqxKo34ILS/C8kt4gX7IM4LQmzvtJFVIYUOuo6+TA86MUKzwteZhzqC7VuxUxB1NDoO1a9TX5p+xL1O5c0L6iUcPb/MI0znP93wDKnR6Yzy+S6wJJpnJePqY/mnEOucmE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de; spf=pass smtp.mailfrom=arndb.de; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b=TU3t05EV; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=E5Q+YBcT; arc=none smtp.client-ip=103.168.172.147 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arndb.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arndb.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=arndb.de header.i=@arndb.de header.b="TU3t05EV"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="E5Q+YBcT" Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfout.phl.internal (Postfix) with ESMTP id 5939213801D4; Wed, 2 Oct 2024 11:45:30 -0400 (EDT) Received: from phl-imap-11 ([10.202.2.101]) by phl-compute-10.internal (MEProxy); Wed, 02 Oct 2024 11:45:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1727883930; x=1727970330; bh=oty9sIPBDyhv/ZrVcebfA4NP1nfbxqi9GsI5LvWrrbY=; b= TU3t05EVvnf+3c0sOGvgfnxfzdU7aSj5aDYQ8lyymUzkbF1u0H28xAnzXyVimMqC LFFVUXpQLq1qFq7ZuIaxYPr0hH1RLmMWCF4VegzeRud3I23Kw6e0qv8itsHk1NlJ JQSvD1HeK0OXbQy0b5nbqpMGx9jXgK1iUyqFbihKrN+7m2tADmb5GgggAYcjqwps pvbBlVM/XcHxmmeuxaDAugd0ig/wm7XsQ5/KM2NMVY2iAc4pDjcMz0fgrCSuZcQf 1dpUjBNN7FJacGQ/6QrW/IGjEf8Iqfpqd5m90OLaVliSFkD2jFn4AvwuyfSNHOhD U2r1AB0zc39ROTeA8yib7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1727883930; x= 1727970330; bh=oty9sIPBDyhv/ZrVcebfA4NP1nfbxqi9GsI5LvWrrbY=; b=E 5Q+YBcTJFwGrltbC587xsM4eizoIksjMfg0VYZF9YOC4UKOtwkXIu/Hb5+mrAexQ 1Ksfj/NQGrpnMylYRj5WG6ihKwXHBm+i+kH18nYwDWz95W+RCMGmJiZkDFNjkX7D NP3y1Q/gvfXDcPQUNHblmjtDfiqQ4Op5td3XYrqxUe4IOoKzmzpkSWgib9EHnZd2 Cl+NbIRv2ncqw4Em48HotsxzAF9c7Mxl/XwiiTvSXET1NVU9yuPfr/CddxWcfHua bcmTiAd9Rp/oCTna/2BLOdOfH/W8mPOEeLh1wJOeJ/X8ezLmXYgsdUFoVz1FWpmG Oe/rcXGetx+ZFi+bdSAKQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdduledgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddt necuhfhrohhmpedftehrnhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrd guvgeqnecuggftrfgrthhtvghrnhephfdthfdvtdefhedukeetgefggffhjeeggeetfefg gfevudegudevledvkefhvdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheprghrnhgusegrrhhnuggsrdguvgdpnhgspghrtghpthhtohepudeh pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopehgrghrhiesghgrrhihghhuohdrnh gvthdprhgtphhtthhopegsohhquhhnrdhfvghnghesghhmrghilhdrtghomhdprhgtphht thhopegrlhhitggvrhihhhhlsehgohhoghhlvgdrtghomhdprhgtphhtthhopegrrdhhih hnuggsohhrgheskhgvrhhnvghlrdhorhhgpdhrtghpthhtohepsghrrghunhgvrheskhgv rhhnvghlrdhorhhgpdhrtghpthhtohepohhjvggurgeskhgvrhhnvghlrdhorhhgpdhrtg hpthhtohepghhrvghgkhhhsehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhrtghp thhtohepsggvnhhnohdrlhhoshhsihhnsehprhhothhonhdrmhgvpdhrtghpthhtohepsg hjohhrnhefpghghhesphhrohhtohhnmhgrihhlrdgtohhm X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 9027B2220071; Wed, 2 Oct 2024 11:45:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Date: Wed, 02 Oct 2024 15:45:08 +0000 From: "Arnd Bergmann" To: "Christian Brauner" , "Alice Ryhl" Cc: "Greg Kroah-Hartman" , "Miguel Ojeda" , "Alexander Viro" , "Jan Kara" , "Boqun Feng" , "Gary Guo" , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , rust-for-linux@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Message-Id: <10dca723-73e2-4757-8e94-22407f069a75@app.fastmail.com> In-Reply-To: <20241002-inbegriff-getadelt-9275ce925594@brauner> References: <20241001-b4-miscdevice-v2-0-330d760041fa@google.com> <20241001-b4-miscdevice-v2-2-330d760041fa@google.com> <20241002-rabiat-ehren-8c3d1f5a133d@brauner> <20241002-inbegriff-getadelt-9275ce925594@brauner> Subject: Re: [PATCH v2 2/2] rust: miscdevice: add base miscdevice abstraction Content-Type: text/plain Content-Transfer-Encoding: 7bit On Wed, Oct 2, 2024, at 14:23, Christian Brauner wrote: > and then copy the stuff via copy_struct_from_user() or copy back out to > user via other means. > > This way you can safely extend ioctl()s in a backward and forward > compatible manner and if we can enforce this for new drivers then I > think that's what we should do. I don't see much value in building generic code for ioctl around this specific variant of extensibility. Extending ioctl commands by having a larger structure that results in a new cmd code constant is fine, but there is little difference between doing this with the same or a different 'nr' value. Most drivers just always use a new nr here, and I see no reason to discourage that. There is actually a small risk in your example where it can break if you have the same size between native and compat variants of the same command, like struct old { long a; }; struct new { long a; int b; }; Here, the 64-bit 'old' has the same size as the 32-bit 'new', so if we try to handle them in a shared native/compat ioctl function, this needs an extra in_conmpat_syscall() check that adds complexity and is easy to forget. Arnd