[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72nVPag-9c73rVTpm5A6BOtM0jq9f9n-dobP8QDOoK5EJQ@mail.gmail.com>
Date: Mon, 17 Mar 2025 16:57:15 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Tamir Duberstein <tamird@...il.com>
Cc: Benno Lossin <benno.lossin@...ton.me>, Danilo Krummrich <dakr@...nel.org>,
Andrew Ballance <andrewjballance@...il.com>, Alice Ryhl <aliceryhl@...gle.com>,
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>,
Andreas Hindborg <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] rust: alloc: add `Vec::dec_len`
On Mon, Mar 17, 2025 at 4:38 PM Tamir Duberstein <tamird@...il.com> wrote:
>
> It is my understanding that the kernel's policy is in general not to
> add API surface that doesn't have users. Rust-for-Linux of course
> often doesn't honor this by necessity, since many abstractions are
> needed before users (drivers) can be upstream. But in this case we
> can't even mention a specific use case - so as I mentioned on the
> previous reply, I am not comfortable putting my name on such an API.
To clarify: as long as the future user is known and agreed upon, it is
fine, i.e. what cannot be done, and we do honor it, is to add things
that have no user in sight at all.
>From time to time, but not really often at all, we have added things
that will obviously get users eventually even if there is currently no
one. For instance, all the `pr_*` levels, even if we do not have a
caller yet for some of them (in that case, because it is simpler to
add all at once instead of asking for reviews several times for
essentially the same code).
Cheers,
Miguel
Powered by blists - more mailing lists