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 1E9068F6B; Wed, 8 Jan 2025 14:20:45 +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=1736346046; cv=none; b=QshHIU/eUywHKMhPsnPzEAuHOg/xez5YclT+TtYlmH3qRhkMoieQWgL8mEE0LX6Ls48mcvs9gXXtukaB7yYmzF+Bvbg0iI2uJpRvlkZuYXtHNX0bVY0VOh6rAGZus4Ikl9ju4NaIQa1XzVhnzYSEFJVVEn9lt4RBl/+Q6A0xo/E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736346046; c=relaxed/simple; bh=+Ks5b42G4hIg6Ccv4uHBqGHIoJUD+5AVSo+CfnmUnYo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=i8eCdX35j0kAy/CamQC7xBPNonpF32GHASgJd/qLn9OiXCsWfcEsqDtngLCAQhPQJUbIU7R5D9MyJySdeeNifd+K2f+WlIaf8yB2yvtUWvNkL7fTYpr/maObEjcCl/NwqaJC6kwz8b7tb2jQL57UqCgvmyOzi5VYrLVIi1SOeds= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NQgJpl6G; 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="NQgJpl6G" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECAF6C4CED3; Wed, 8 Jan 2025 14:20:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736346045; bh=+Ks5b42G4hIg6Ccv4uHBqGHIoJUD+5AVSo+CfnmUnYo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NQgJpl6GuejCujL+PyOXqOIH1YkX6FdjFZg2aAw7zumcKvG4hi9OTStvVTc/kDMd+ YrQrKraB/LaqMBURCUy2RJH+SguI+GJHx6LVtjTd88mJYVO31eoVOhZg/M9JpCL5jv RDMp92LPvXSIS5SZAyf4t1MLiNohUuWchLZPku/Yeoe7ZiQXR/Zxg+jX90x+gsvzsc Xs3ZV3xM9FQuv7nRrxwSB6KEET0iLZmhtrgPTZ627bk/kyxxdJcqhQYbUAhOPIDADW CO5DnhK1hYyCD+d6p/wsSHkdYmeBXx0wkI+6DgTY+f3za4HcJP97nOxTdPjECZL+cJ MrnZp3qd6TwNA== From: Andreas Hindborg To: "Miguel Ojeda" Cc: "Miguel Ojeda" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , "Benno Lossin" , "Alice Ryhl" , "Masahiro Yamada" , "Nathan Chancellor" , "Nicolas Schier" , "Trevor Gross" , "Adam Bratschi-Kaye" , , , Subject: Re: [PATCH v3 4/4] rust: add parameter support to the `module!` macro In-Reply-To: (Miguel Ojeda's message of "Wed, 08 Jan 2025 14:43:31 +0100") References: <20241213-module-params-v3-v3-0-485a015ac2cf@kernel.org> <20241213-module-params-v3-v3-4-485a015ac2cf@kernel.org> <87y10jd8o0.fsf@kernel.org> <87tta9bhjz.fsf@kernel.org> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Wed, 08 Jan 2025 15:20:33 +0100 Message-ID: <87ldvlbd5a.fsf@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Miguel Ojeda" writes: > On Wed, Jan 8, 2025 at 1:45=E2=80=AFPM Andreas Hindborg wrote: >> >> I don't think we ever discussed this? > > I don't think so -- we discussed other things related to 2025H1 the > last meeting. Perhaps you/we can bring it up in the next one? > >> Version 3 of this patch enabled the unstable feature `sync_unsafe_cell` = [1] to >> avoid `static mut` variables as suggested by Trevor Tross and Benno Loss= in [2]. >> >> As we are moving closer to a new edition, it is now clear that `static m= ut` is >> not being deprecated in the 2024 edition as first anticipated [3]. >> >> Still, `SyncUnsafeCell` allows us to use safe code when referring to the >> parameter value: > >> What do you think? > > The justification seems fairly weak... Unless we are fairly confident > the API will be stable (even if not stabilized right now), I am not > sure why we would want to do this right now. > > Can we provide our own `SyncUnsafeCell` instead in the meantime, if > you want to keep the advantages? I like having the shared `ModuleParamAccess` struct to encapsulate the acce= ss to the parameters rather than emitting an enum for every parameter instance. For that to work without unsafe code when the user accesses the parameter value, we need a non-mutable static that provides interior mutability. I could implement `Sync` for `ModuleParamAccess` or I could add `kernel::types::SyncUnsafeCell`. Either way is fine for me. > >> Returning an error and `pr_warn!` is doable. As far as I can tell, we do >> not have `WARN_ON_ONCE` yet? > > Please see https://lore.kernel.org/rust-for-linux/20241126-pr_once_macros= -v4-0-410b8ca9643e@tuta.io/ > in case it helps. Cool, I can list that as a prerequisite. Best regards, Andreas Hindborg