From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C282ECE564 for ; Tue, 10 Sep 2024 13:23:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61BD98D0068; Tue, 10 Sep 2024 09:23:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 57DC78D0002; Tue, 10 Sep 2024 09:23:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 41E558D0068; Tue, 10 Sep 2024 09:23:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1BAA18D0002 for ; Tue, 10 Sep 2024 09:23:58 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id C1EEE80390 for ; Tue, 10 Sep 2024 13:23:57 +0000 (UTC) X-FDA: 82548896514.04.E50860C Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf17.hostedemail.com (Postfix) with ESMTP id 364F740006 for ; Tue, 10 Sep 2024 13:23:55 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=A4Fd0LAx; spf=pass (imf17.hostedemail.com: domain of dakr@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725974498; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PJ+9nY77SI4aQh/O5oQWLQg8yL4Yb2tQlc28H70xjuo=; b=YRCGazIRMWh7F8Gez+uLZPhXRsZrEtTPzcJKbfJnsLR6B66LgH8sgK9NkEwbYWaKGZD/3S uwtpyITnBSbwXBt+LOnr7jLCKZCaHdu9cTrru6+NvkdeidlrmKSFw1D8WeoROhdR3YBu7X dwZdJB5rAhm/qOL3wOJwnRm2PN25yx0= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=A4Fd0LAx; spf=pass (imf17.hostedemail.com: domain of dakr@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=dakr@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725974498; a=rsa-sha256; cv=none; b=0QAqs8M9xOzV7qRDIas2+e4q47yg0YFZAn79ialY+WCZNvY9hzuIgOItHM6+57CI7pOPmS mkhAEv5FkWIXBa3BjvVzysrGv8LZmsvkujp4wubBFweqh5ospDMAT4mgwqZAPkyRWkjHSI nbX76dsr9Dh7nRFdErRaoqVUOL/qGd4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id B3A09A44781; Tue, 10 Sep 2024 13:23:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15A94C4CEC4; Tue, 10 Sep 2024 13:23:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725974633; bh=LFb2YHlrS3wGYB3pz6ZfwEjzOnQjkSzgEc19Fpysuh8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=A4Fd0LAxzkz4uP/JKACsrqfRhozSxFHdSAR2K2VqcpDdLpscgVmpjnh8mrF50pPfR ZRc4EMILUQOpoWe3Uc+QONeXCYucqsH5qxro6u/+q9D2qMC/dPRANDh5TV/BoKqko2 8Tq0z3nGIP6fkMD3o86PC3pX50izL8XVeoDdHxdfGc2bAMtEES8qx73L0UZS/KZhaw dLKozQiDluu31rpkY8fN3bIqToeZeKj6xjgCDJE/K3+aw7/uG9Qf1hv2vtkQ087cop jgya0xuSEAtxOO7t3A3/nHATv3iUOg5qmC93Ss/do8k0/FwpSc05HQY3puU1YqtIR+ OQNcQsnSvzv9Q== Date: Tue, 10 Sep 2024 15:23:44 +0200 From: Danilo Krummrich To: Benno Lossin Cc: ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@samsung.com, aliceryhl@google.com, akpm@linux-foundation.org, daniel.almeida@collabora.com, faith.ekstrand@collabora.com, boris.brezillon@collabora.com, lina@asahilina.net, mcanal@igalia.com, zhiw@nvidia.com, cjia@nvidia.com, jhubbard@nvidia.com, airlied@redhat.com, ajanulgu@redhat.com, lyude@redhat.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v6 01/26] rust: alloc: add `Allocator` trait Message-ID: References: <20240816001216.26575-1-dakr@kernel.org> <20240816001216.26575-2-dakr@kernel.org> <60253988-37e7-4acb-b2ae-748b30a4ac21@proton.me> <44b80095-8b03-4558-967e-138ea712f780@proton.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 364F740006 X-Stat-Signature: bjg33bzhr7zf5oxwbgowgd8odgmohcex X-Rspam-User: X-HE-Tag: 1725974635-459343 X-HE-Meta: U2FsdGVkX1+1TXowCq3lMXzuL8+8nZZ1HGbP7pbgcR/up3GiwuKj1NH+XsHDcwsNPFAN90jfFQIip6IyrCQS/nHvc8NthfoqGBGTcAv6/ym5TKScpIvK3YgO0hMs3GkwB6WFBf3hw2nQu7o1eQxdSbJnxyoWk5qDxWqmiX10s3crwNndUhK9BsP4XknAv1O0DOknm2BzlsPCWaohiQZ4FHPu06fmrx068ATKhW5HwWi1bPzX7+tJ1ECRMUUfFJVOYVkHGIYwIXQGECqWCX2Sf2PvHnCrpzJtew9lys6OC88fNWhgNAugbhW4WdP1wUNbkJmgorRQa1Em2RfCl+IF3HeCA7MGPgJheoLlX/YBpNgjQmdi/Gt9N8ZcrLXd+ngYhpZipYC2PohAze8Kg1NLJgCi+vvLpdo91LpH09KqQQWfgZet25cL9DrcD+hmkQe49iOCAzsdwoS8pDnV4k+r/ckRct8+e0WXSyua7RRkY5UgDwWrQjLjaBnqn+4iHRmXK+JYuhF8UvT4Gde0eaS5osR4WTxtbPLqHKysNOYRgkGUchOUE6y2n8QnVqtk6eP1vW1c+UIiRTwLlQFaqhvJuks8PXnGjz4t82EZZSqZLVWbWgMVGp1voXpi9yrfM5UF+p4Qul2NbkaIIOjV3V9AjALEkRvw8c/NeiMyd13ghQvUvNPfRp6aqiQHO45YBKrkBtdn3tiLcLWi/H8mkdJoVRFSCA0Yv8KpobTi0TqeQFG1bf10h811K7GNUDIrbPAAWEl07tb/3rABFbh3jjZZ7SjECyNTSemXEeVwCKLlVRLgIGo4MyYYQtm0fX1drtMIjORcnXFy0fJ0qmMscpD1n6gon2UKp6QjQnqBXhbETWfYVlMbcJk4HzYQUZ6r6z+qpU8tapBIxqwlRL7A8JTsinKQfUS5iEyBechfgDcQKCvvqaTDZNL1fpYUyVOVR6qQfk1XU6xEzAX0ERaoRaa 1WSJs+or 0y2HAum+nNZR3EBJrMkMT36HiBiezCvalAyfsHFrN+b09zt7aw3LN9Kd4eZT/XmckIVgptJR/NcqHpQDAAWVnLabrbe9gZr0luH1RkGofoAEeyy2kf6ilwL8NOuPwiTe7l0yptUQQ4fQpz4bIfE2Zya996wBsr5BuYE634y1GSAIBIeqXQ1Y9IaY7q28/LLXOUUnXluae7jzYa1Kb/SjVMUNifQuVTBwKfjqiURQn3+nGKZ5Vt7ZLJSqBGs1jbUvCWy1NN8dCCwYCETaMlzevHEhVVqjt2fOkpPp0Azec7iLUT5EfoFRiobzyU9FFV0C4tMNN4FyweaG+ekTuH0ZKZuIwnYV6UA0Ix6qLmfFTnPRRQpNFEGtIil+wXw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Sep 10, 2024 at 01:03:48PM +0000, Benno Lossin wrote: > On 03.09.24 13:56, Danilo Krummrich wrote: > > 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 > >>>>> Signed-off-by: Danilo Krummrich > >>>> > >>>> 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. > > Agreed, but I don't want people to think that we have a reason against > doing it in the future. Do you have an idea how to convey this? I understand (and agree with) your intention. But I don't think it's necessary to document, because, ideally, this is already true for the whole kernel. Generally, I think it's valid to assume that people are willing to change the code if the advantages outweigh the disadvantages. So, we could write something like "This may be changed if the advantages outweigh the disadvantages.", but it'd be a bit random, since we could probably sprinkle this everywhere. > > --- > Cheers, > Benno >