From: Shivam Kalra <shivamkalra98@gmail.com>
To: Danilo Krummrich <dakr@kernel.org>,
Alice Ryhl <aliceryhl@google.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/4] rust: alloc: add Vec shrinking methods
Date: Wed, 11 Feb 2026 06:38:24 +0530 [thread overview]
Message-ID: <1312bba9-442b-410a-9cb4-fe67879d2dcb@gmail.com> (raw)
In-Reply-To: <DGBLALCUGY7N.383JKRKNCRDW5@kernel.org>
On 11/02/26 02:41, Danilo Krummrich wrote:
> On Tue Feb 10, 2026 at 9:58 PM CET, Alice Ryhl wrote:
>> On Tue, Feb 10, 2026 at 9:54 PM Danilo Krummrich <dakr@kernel.org> wrote:
>> Yes that's what I meant. Only provide shrink_to() for those. After
>> all, if Kmalloc never actually shrinks when you call realloc, what's
>> the point of having KVec::shrink_to()?
>
> Nothing, but eventually we want a generic impl of shrink_to() with A::realloc().
> But again, for now that's fine.
Thanks for the discussion. Just want to confirm my understanding
of the agreed approach:
Since VVec and KVVec are type aliases for Vec<T, Vmalloc> and
Vec<T, KVmalloc>, implementing shrink_to() on "only VVec and KVVec"
means writing separate impl blocks:
impl<T> Vec<T, Vmalloc> { fn shrink_to() { ... } }
impl<T> Vec<T, KVmalloc> { fn shrink_to() { ... } }
Is that what you had in mind, with the shrink logic duplicated
in both? Or would you prefer a shared impl with a trait bound to
avoid duplication?
next prev parent reply other threads:[~2026-02-11 1:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-07 11:32 Shivam Kalra via B4 Relay
2026-02-07 11:32 ` [PATCH v3 1/4] rust: alloc: introduce Shrinkable trait Shivam Kalra via B4 Relay
2026-02-07 11:32 ` [PATCH v3 2/4] rust: kvec: implement shrink_to and shrink_to_fit for Vec Shivam Kalra via B4 Relay
2026-02-07 17:23 ` Danilo Krummrich
2026-02-08 16:11 ` Shivam Kalra
2026-02-07 11:32 ` [PATCH v3 3/4] rust: alloc: add KUnit tests for Vec shrink operations Shivam Kalra via B4 Relay
2026-02-07 11:32 ` [PATCH v3 4/4] rust: binder: shrink all_procs when deregistering processes Shivam Kalra via B4 Relay
2026-02-09 13:54 ` Alice Ryhl
2026-02-10 11:47 ` Shivam Kalra
2026-02-10 13:38 ` [PATCH v3 0/4] rust: alloc: add Vec shrinking methods Shivam Kalra
2026-02-10 13:57 ` Alice Ryhl
2026-02-10 15:05 ` Danilo Krummrich
2026-02-10 17:42 ` Shivam Kalra
2026-02-10 20:05 ` Alice Ryhl
2026-02-10 20:43 ` Danilo Krummrich
2026-02-10 20:53 ` Danilo Krummrich
2026-02-10 20:56 ` Danilo Krummrich
2026-02-10 20:58 ` Alice Ryhl
2026-02-10 21:11 ` Danilo Krummrich
2026-02-11 1:08 ` Shivam Kalra [this message]
2026-02-11 6:51 ` Alice Ryhl
2026-02-11 8:41 ` Shivam Kalra
2026-02-11 8:57 ` Danilo Krummrich
2026-02-11 9:35 ` Shivam Kalra
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=1312bba9-442b-410a-9cb4-fe67879d2dcb@gmail.com \
--to=shivamkalra98@gmail.com \
--cc=aliceryhl@google.com \
--cc=dakr@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rust-for-linux@vger.kernel.org \
/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
all inboxes | Powered by JetHome®