From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9F6DD1D618E; Tue, 1 Jul 2025 15:43:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751384618; cv=none; b=rpfhKgAm2tn32MS/bP+6uQqPVgXH7B7FPSkCk3Qj47VDt1ugbtTQ2sqxYZJqMrUMrq2cIHifns24Q3/NgD1jkNwnXZrSrWubCuBBAkDVZqfaP/XaAJIRRMHp/fpGKAk7wRjZouClsyog4/7krX3Stdgbkh5iAMJXMCcVaLlnsmw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751384618; c=relaxed/simple; bh=GmFWLrGBSZdojzb5yeGcOhRuy7723mG21OKyyQ30XPY=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=IK/K5c9pwfaqYHBaQfBKsWdPfCRpMP9ytrj8g2GlIxghLLq9A9/MbRyhgcusR3TBoA9DuUP6SgEjoE3fQp1DK9YJduhnwzZ20IWUD2QaqT6EhzbocELNL2sD9+mMjyLPErYfnTo1Mpz7oaaXLjtzLmIEYUtSvIw0JCTs/pwQizQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZgQ45D4e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZgQ45D4e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E33EC4CEEB; Tue, 1 Jul 2025 15:43:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751384616; bh=GmFWLrGBSZdojzb5yeGcOhRuy7723mG21OKyyQ30XPY=; h=Date:Cc:Subject:From:To:References:In-Reply-To:From; b=ZgQ45D4e9fh85CIBRT85kGukRTNPnT/4oPh38PgpYAwtxwPp5u62ziD5bxmatg6lE uxieHeVivqSp5U0b+zYQxz7pNnvjg1xEdJCnZUyZA4ESRHMLxyAWKQ7ePPhopcdl1z rMStGNl0sF9y9wXv8dbiPwJM/1ZnQweGHlCihqO9hQzjE3sjiZQzFeP/Jt5DWrcfmD sB+/tm3091cYzO4IxHaGGsIjpcjlGHxfovLlkqNUe60xSJG8PXV6YL23BkOgw2L97J Va54TfXLL0eKoVDc7AQg5NIhJshUH2pILknPEPOxe6w2jDQ636ER9+Vn1hIL8vD8Bo KZxbz1yF7fGQw== Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 01 Jul 2025 17:43:29 +0200 Message-Id: Cc: "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Alice Ryhl" , "Masahiro Yamada" , "Nathan Chancellor" , "Luis Chamberlain" , "Danilo Krummrich" , "Nicolas Schier" , "Trevor Gross" , "Adam Bratschi-Kaye" , , , , "Petr Pavlu" , "Sami Tolvanen" , "Daniel Gomez" , "Simona Vetter" , "Greg KH" , "Fiona Behrens" , "Daniel Almeida" , Subject: Re: [PATCH v13 2/6] rust: introduce module_param module From: "Benno Lossin" To: "Andreas Hindborg" X-Mailer: aerc 0.20.1 References: <20250612-module-params-v3-v13-0-bc219cd1a3f8@kernel.org> <877c126bce.fsf@kernel.org> <87v7om4jhq.fsf@kernel.org> <878qlh4aj1.fsf@kernel.org> <87plepzke5.fsf@kernel.org> <87wm8txysl.fsf@kernel.org> <9G3W1seaM7elcwWXaeoaa2nfpFYCf-AmBdvZhACGP13KGUtTPVMwGNYdTQsdtp8ru7GIP3-UYTzXscC1MRUKrg==@protonmail.internalid> <87h5zxxtdw.fsf@kernel.org> <87bjq4xpv7.fsf@kernel.org> <87zfdovvz4.fsf@kernel.org> In-Reply-To: <87zfdovvz4.fsf@kernel.org> On Tue Jul 1, 2025 at 4:14 PM CEST, Andreas Hindborg wrote: > "Benno Lossin" writes: >> On Tue Jul 1, 2025 at 10:43 AM CEST, Andreas Hindborg wrote: >>> No, I am OK for now with configfs. >>> >>> But, progress is still great. How about if we add a copy accessor >>> instead for now, I think you proposed that a few million emails ago: >>> >>> pub fn get(&self) -> T; >>> >>> or maybe rename: >>> >>> pub fn copy(&self) -> T; >>> >>> Then we are fine safety wise for now, right? It is even sensible for >>> these `T: Copy` types. >> >> That is better than getting a reference, but still someone could read at >> the same time that a write is happening (though we need some new >> abstractions AFAIK?). But I fear that we forget about this issue, >> because it'll be some time until we land parameters that are `!Copy` (if >> at all...) > > No, that could not happen when we are not allowing custom parsing or > sysfs access. Regarding forgetting, I already added a `NOTE` on `!Copy`, > and I would add one on this issue as well. Ultimately this is something for Miguel to decide. I would support an unsafe accessor (we should also make it `-> T`), since there it "can't go wrong", any UB is the fault of the user of the API. It also serves as a good reminder, since a `NOTE` comment shouldn't be something guaranteeing safety (we do have some of these global invariants, but I feel like this one is too tribal and doesn't usually come up, so I feel like it's more dangerous). I think we should also move this patchset along, we could also opt for no accessor at all :) Then it isn't really useful without the downstream accessor function, but that can come after. --- Cheers, Benno