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 90DCF211F; Wed, 2 Jul 2025 07:57:02 +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=1751443022; cv=none; b=t3T72Ht9UB0PEUfniZlKb+cA8yM9SN4XbAGWEEFxl9Dvx8UWIfs6AN2GPqdKiQ6g2qVEeHqt7MXtPIiz8IAFe221ekZv1bc3QrRDxWjrp1WmPufSK2GnsPqwwAkiYLJ+G2sDFVkVVqApw2FGYjGgTexmp2kIUBAS5LO0n1NWg3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1751443022; c=relaxed/simple; bh=iPRdlhGWfx9VLtmj4Qr358Ma925NEGSXkWBmva+PDXA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=plkB7jo3AHMw9b8GRYXVf0e6H++nt1Wt5nO9rgDI6HxMSJyDrl6KjdLUXbq3g+S5cH4K978mUalvmEL3kcmwmUw7DNPTovnyF6TJzvSRqhbz0IDmg0dbDrJXPE5GeiD5GBPJXVsZPol9lS1R3kiCkw7l7vurvdtp7TBw7N65/7g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jDAJOT7H; 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="jDAJOT7H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D4BDC4CEED; Wed, 2 Jul 2025 07:56:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1751443022; bh=iPRdlhGWfx9VLtmj4Qr358Ma925NEGSXkWBmva+PDXA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jDAJOT7HLum6yiMRluiGc4tMSFC54IRmLsQrSvdr2uOF6JHJgGCg3CpR9fHpPRDNy j5g2vjUhlis20IrYgZ9S2CfzylqaQ9ayGZ8GA72tEsMogJciaC0a+g9eHB8KXv5YK9 y7XQV8ecp2z/J3SjobB3j/rGb3CVKpQF3wexh+SrXIns+8W70gUfT+NcYlhusCGB/b tiNebM/8pvcgVwXhS/sIxMbUYIBziCMDvbrVi8jbpUPkcxvakHCJB9QbzY25s2Kke9 AsKGkUI7mW/57u+FwKv0XSEL2Kg1IWZme0S6itxsB8+0y+L+shI39jyHpMg+g6e2RF JGtMVN77NvWhw== From: Andreas Hindborg To: "Benno Lossin" 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 In-Reply-To: (Benno Lossin's message of "Tue, 01 Jul 2025 17:43:29 +0200") References: <20250612-module-params-v3-v13-0-bc219cd1a3f8@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> User-Agent: mu4e 1.12.9; emacs 30.1 Date: Wed, 02 Jul 2025 09:56:50 +0200 Message-ID: <87tt3vvxdp.fsf@kernel.org> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Benno Lossin" writes: > 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 see no reason for making it unsafe when it is safe? /// Get a copy of the parameter value. /// /// # Note /// /// When this method is called in `const` context, the default /// parameter value will be returned. During module initialization, the /// kernel will populate the parameter with the value supplied at module /// load time or kernel boot time. // NOTE: When sysfs access to parameters are enabled, we have to pass in a // held lock guard here. // // NOTE: When we begin supporting custom parameter parsing with user // supplied code, this method must be synchronized. pub const fn copy(&self) -> T { // SAFETY: As we only support read only parameters with no sysfs // exposure, the kernel will not touch the parameter data after module // initialization. The kernel will update the parameters serially, so we // will not race with other accesses. unsafe { *self.data.get() } } > > 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. I would rather not merge it without an access method. Then it is just dead code, and we will not notice if we break it. Best regards, Andreas Hindborg