Re: [PATCH v6 01/26] rust: alloc: add `Allocator` trait

[Danilo Krummrich <dakr@kernel.org>]

On Fri, Aug 30, 2024 at 01:06:00PM +0000, Benno Lossin wrote:
> On 29.08.24 23:56, Danilo Krummrich wrote:
> > On Thu, Aug 29, 2024 at 06:19:09PM +0000, Benno Lossin wrote:
> >> On 16.08.24 02:10, Danilo Krummrich wrote:
> >>> Add a kernel specific `Allocator` trait, that in contrast to the one in
> >>> Rust's core library doesn't require unstable features and supports GFP
> >>> flags.
> >>>
> >>> Subsequent patches add the following trait implementors: `Kmalloc`,
> >>> `Vmalloc` and `KVmalloc`.
> >>>
> >>> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
> >>> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
> >>
> >> We discussed this in our weekly meeting (I think ~one week ago?). If you
> >> give me a draft version of the comment that you plan to add regarding
> >> the `old_layout` parameter, I can see if I am happy with it. If I am, I
> >> would give you my RB.
> > 
> > May I propose you let me know what you would like to see covered, rather than
> > me trying to guess it. :-)
> 
> I was hoping that we put that in our meeting notes, but I failed to find
> them... I would put this in a normal comment, so it doesn't show up in the
> documentation. Preface it like implementation decision/detail:
> - Why do `Allocator::{realloc,free}` not have an `old_layout` parameter
>   like in the stdlib? (the reasons you had for that decision, like we
>   don't need it etc.)

Ok.

> - Then something along the lines of "Note that no technical reason is
>   listed above, so if you need/want to implement an allocator taking
>   advantage of that, you can change it"

I don't really want to set the conditions for this to change in the
documentation. It really depends on whether it's actually needed or the
advantage of having it is huge enough to leave the core kernel allocators with
unused arguments.

This can really only be properly evaluated case by case in a discussion.

> 
> I don't think we need a lot here. Additionally it would be very useful
> to also put this in an issue to not lose track of it.
> 
> ---
> Cheers,
> Benno
>