[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024121324-ravine-kinswoman-c0d1@gregkh>
Date: Fri, 13 Dec 2024 12:46:13 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Alice Ryhl <aliceryhl@...gle.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>,
Trevor Gross <tmgross@...ch.edu>,
Adam Bratschi-Kaye <ark.email@...il.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v3 4/4] rust: add parameter support to the `module!` macro
On Fri, Dec 13, 2024 at 12:30:49PM +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.
read-only is VERY limited, and as such, only good for boot options,
which as I mentioned before, is not how any "modern" kernel driver
should be doing things.
And no sysfs interaction? That's going to confuse the heck out of
people wondering why the option they added doesn't show up in the same
place it normally would if they did it in C, right? Not that I'm saying
this should be done at all, just that this is going to be confusing
right off the bat which is probably not a good idea.
Friends don't let friends add new module parameters to the kernel :)
thanks,
greg k-h
Powered by blists - more mailing lists