From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Greg KH" <gregkh@linuxfoundation.org>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Alice Ryhl" <aliceryhl@google.com>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Nathan Chancellor" <nathan@kernel.org>,
"Nicolas Schier" <nicolas@fjasle.eu>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Adam Bratschi-Kaye" <ark.email@gmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kbuild@vger.kernel.org, "Petr Pavlu" <petr.pavlu@suse.com>,
"Sami Tolvanen" <samitolvanen@google.com>,
"Daniel Gomez" <da.gomez@samsung.com>,
"Simona Vetter" <simona.vetter@ffwll.ch>,
linux-modules@vger.kernel.org
Subject: Re: [PATCH v4 4/4] rust: add parameter support to the `module!` macro
Date: Thu, 09 Jan 2025 14:03:39 +0100 [thread overview]
Message-ID: <87h6689m1g.fsf@kernel.org> (raw)
In-Reply-To: <2025010953-saint-share-fc41@gregkh> (Greg KH's message of "Thu, 09 Jan 2025 12:27:10 +0100")
"Greg KH" <gregkh@linuxfoundation.org> writes:
> On Thu, Jan 09, 2025 at 11:54:59AM +0100, Andreas Hindborg wrote:
>> This patch includes changes required for Rust kernel modules to utilize
>> module parameters. This code implements read only support for integer
>> types without `sysfs` support.
>
> I know you want to keep this simple for now, but will you have to go and
> touch all users of this when you do add the sysfs support later? sysfs
> wants the mode of the file to be set here, so how do you think of that
> happening?
We would add the required fields to the `module!` macro as optional
fields. No need to touch everyone. Leaving out the sysfs file permission
field would cause the parameter to not show up in sysfs.
> And don't you need that for your null block driver?
Yes I need it eventually.
> Also, what about all the other "types" of module parameters that are
> currently able to be done, like call-back, hardware control, and unsafe?
> Are we just not going to do that for rust code (no objection from me,
> just wanting to be sure.)
Someone told me "no dead code", so I would defer those features to when
we have a user.
We have blueprints for strings and arrays based on Adams earlier
work.
I don't imagine any rust code relying on hw param and the use in the
kernel seems to be very limited.
Not sure about cb params. While it might be nice for the user to be able
to pass a callback to decode/sanitize , the same effect could be
achieved by putting the logic elsewhere. I don't have an idea of how to
implement this in Rust at the moment, but I am sure we can come up with
a solution if we need to.
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2025-01-09 13:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-09 10:54 [PATCH v4 0/4] rust: extend `module!` macro with integer parameter support Andreas Hindborg
2025-01-09 10:54 ` [PATCH v4 1/4] rust: str: implement `PartialEq` for `BStr` Andreas Hindborg
2025-01-15 19:35 ` Gary Guo
2025-01-09 10:54 ` [PATCH v4 2/4] rust: str: implement `strip_prefix` " Andreas Hindborg
2025-01-09 12:06 ` Alice Ryhl
2025-01-15 19:35 ` Gary Guo
2025-01-09 10:54 ` [PATCH v4 3/4] rust: str: add radix prefixed integer parsing functions Andreas Hindborg
2025-01-15 19:42 ` Gary Guo
2025-02-04 9:51 ` Andreas Hindborg
2025-01-09 10:54 ` [PATCH v4 4/4] rust: add parameter support to the `module!` macro Andreas Hindborg
2025-01-09 11:27 ` Greg KH
2025-01-09 13:03 ` Andreas Hindborg [this message]
2025-01-09 17:17 ` Greg KH
2025-01-22 16:01 ` Petr Pavlu
2025-01-22 20:06 ` Andreas Hindborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h6689m1g.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=ark.email@gmail.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=da.gomez@samsung.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas@fjasle.eu \
--cc=ojeda@kernel.org \
--cc=petr.pavlu@suse.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=simona.vetter@ffwll.ch \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).