[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANiq72=5vcBcOwcX5dadp45G+dvRRwpy1KrEXpEANbOW4gPPew@mail.gmail.com>
Date: Tue, 31 Jan 2023 21:46:58 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Martin Rodriguez Reboredo <yakoyoku@...il.com>,
alex.gaynor@...il.com, bjorn3_gh@...tonmail.com,
boqun.feng@...il.com, gary@...yguo.net,
linux-kernel@...r.kernel.org, ojeda@...nel.org,
rust-for-linux@...r.kernel.org, wedsonaf@...il.com
Subject: Re: [PATCH] rust: add this_module macro
On Tue, Jan 31, 2023 at 5:59 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> Right now the rust framework is just that, a framework. Perhaps we
> should not be adding anything else to it until there is a real user of
> it? Otherwise this will keep coming up again and again.
>
> Treat this like any other kernel feature/addition, you can't add apis
> until you submit a user for it at the same time. That's one way we have
> been able to evolve and maintain the kernel source tree for so long.
> Without an api user, we have no way to know how it's being used or if
> it's even being used at all.
Agreed. For this patch, it came independently, so I cannot speak about
its users. For other patch series we have sent, the users are
out-of-tree, but they want to come in-tree as soon as possible. We are
coordinating with them to prioritize the submission of the things they
will depend on.
Since the goal is to submit things piece by piece so that they can be
properly reviewed, what we have been doing to ameliorate things is to
provide enough details, examples and documentation for each function,
type, etc. so that it is hopefully clear how they will be used. If
there are some cases where it may not be clear, we can also link to
the upcoming users.
Cheers,
Miguel
Powered by blists - more mailing lists