public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <dakr@kernel.org>
To: Tamir Duberstein <tamird@gmail.com>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Andrew Ballance" <andrewjballance@gmail.com>,
	"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>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] rust: alloc: add `Vec::dec_len`
Date: Tue, 18 Mar 2025 21:15:45 +0100	[thread overview]
Message-ID: <Z9nUcXc76w5g4_9m@cassiopeiae> (raw)
In-Reply-To: <CAJ-ks9mmkm2LT7BYg3ni0v-PsV4Gv57=SOD1xDp1_aeqN7XPzA@mail.gmail.com>

On Tue, Mar 18, 2025 at 04:13:43PM -0400, Tamir Duberstein wrote:
> On Tue, Mar 18, 2025 at 4:05 PM Tamir Duberstein <tamird@gmail.com> wrote:
> >
> > On Tue, Mar 18, 2025 at 3:27 PM Danilo Krummrich <dakr@kernel.org> wrote:
> > >
> > > On Tue, Mar 18, 2025 at 02:53:48PM -0400, Tamir Duberstein wrote:
> > > > On Tue, Mar 18, 2025 at 2:46 PM Danilo Krummrich <dakr@kernel.org> wrote:
> > > > >
> > > > > On Tue, Mar 18, 2025 at 02:28:02PM -0400, Tamir Duberstein wrote:
> > > > > > On Tue, Mar 18, 2025 at 10:44 AM Alice Ryhl <aliceryhl@google.com> wrote:
> > > > > > >
> > > > > > > On Tue, Mar 18, 2025 at 10:12:28AM -0400, Tamir Duberstein wrote:\
> > > > > > > >
> > > > > > > > The methods you're describing are all on Vec, right? In other words,
> > > > > > > > their usage calls for a private `dec_len` or `set_len`. As I've said
> > > > > > > > repeatedly in the course of this discussion: I would prefer not to
> > > > > > > > introduce `dec_len` at all here. It (or `set_len`) can be introduced
> > > > > > > > in the series that adds truncate or your patch that adds clear, where
> > > > > > > > its signature can be properly scrutinized in the context of an actual
> > > > > > > > caller.
> > > > > > >
> > > > > > > Oh I did not see that you said that. Dropping patch 2 is fine with me.
> > > > > > >
> > > > > > > Alice
> > > > > >
> > > > > > Benno, Danilo: are you both OK with this? I'll discard this patch on
> > > > > > the respin and prepend the patch adding the len <= cap invariant.
> > > > >
> > > > > I mean, the whole reason to switch set_len() to inc_len() and have a separate
> > > > > dec_len() was to properly cover things like [1] and Alice' patch by having
> > > > > dec_len() return the abandoned entries.
> > > > >
> > > > > If we now only switch set_len() to inc_len() and drop dec_len() then what should
> > > > > Andrew do?
> > > >
> > > > I'd be completely fine with Andrew (or Alice) taking this patch into
> > > > the truncate/resize series[1] (or the series that introduces clear
> > > > [2]). It can be properly reviewed there in context.
> > >
> > > Sorry, I'm not willing to make this Andrew's responsibility; set_len() worked
> > > for his patches before.
> > >
> > > If you're uncomfortable implementing your proposal without the existence of
> > > truncate(), please rebase onto Andrew's patches.
> >
> > This suits me just fine! I tried applying Andrew's patches locally but
> > I don't have `Documentation/gpu/nova/core/todo.rst`. Do you know what
> > his base commit is?
> 
> Nevermind, I can just specify the patch ID.

Yeah, you can just ignore the nova patch.

  reply	other threads:[~2025-03-18 20:15 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-16 22:31 [PATCH 0/2] rust: alloc: split `Vec::set_len` into `Vec::{inc,dec}_len` Tamir Duberstein
2025-03-16 22:32 ` [PATCH 1/2] rust: alloc: replace `Vec::set_len` with `inc_len` Tamir Duberstein
2025-03-17  9:58   ` Benno Lossin
2025-03-17 10:23     ` Miguel Ojeda
2025-03-17 14:43       ` Benno Lossin
2025-03-17 10:48     ` Alice Ryhl
2025-03-17 11:25       ` Tamir Duberstein
2025-03-17 14:46         ` Benno Lossin
2025-03-17 15:01           ` Tamir Duberstein
2025-03-17 10:50   ` Alice Ryhl
2025-03-17 11:16     ` Danilo Krummrich
2025-03-17 11:25     ` Tamir Duberstein
2025-03-16 22:32 ` [PATCH 2/2] rust: alloc: add `Vec::dec_len` Tamir Duberstein
2025-03-16 22:35   ` Tamir Duberstein
2025-03-16 22:41   ` Danilo Krummrich
2025-03-16 22:47     ` Tamir Duberstein
2025-03-16 23:02       ` Danilo Krummrich
2025-03-16 23:27         ` Tamir Duberstein
2025-03-17 11:22           ` Danilo Krummrich
2025-03-17 11:34             ` Tamir Duberstein
2025-03-17 10:04   ` Benno Lossin
2025-03-17 11:34     ` Tamir Duberstein
2025-03-17 11:47       ` Alice Ryhl
2025-03-17 12:59         ` Alice Ryhl
2025-03-17 13:53           ` Tamir Duberstein
2025-03-18  9:30             ` Alice Ryhl
2025-03-18 14:12               ` Tamir Duberstein
2025-03-18 14:44                 ` Alice Ryhl
2025-03-18 18:28                   ` Tamir Duberstein
2025-03-18 18:46                     ` Danilo Krummrich
2025-03-18 18:53                       ` Tamir Duberstein
2025-03-18 19:26                         ` Danilo Krummrich
2025-03-18 20:05                           ` Tamir Duberstein
2025-03-18 20:13                             ` Tamir Duberstein
2025-03-18 20:15                               ` Danilo Krummrich [this message]
2025-03-17 14:42           ` Benno Lossin
2025-03-17 14:44             ` Tamir Duberstein
2025-03-17 16:16               ` Danilo Krummrich
2025-03-17 16:21                 ` Tamir Duberstein
2025-03-17 14:39       ` Benno Lossin
2025-03-17 15:37         ` Tamir Duberstein
2025-03-17 15:57           ` Miguel Ojeda
2025-03-17 17:24           ` Benno Lossin
2025-03-17 17:28             ` Tamir Duberstein
2025-03-19 21:05   ` kernel test robot

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=Z9nUcXc76w5g4_9m@cassiopeiae \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=andrewjballance@gmail.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@gmail.com \
    --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