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 E9046C52D7C for ; Thu, 15 Aug 2024 14:09:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 668366B00F4; Thu, 15 Aug 2024 10:09:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 618416B0107; Thu, 15 Aug 2024 10:09:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DF586B0108; Thu, 15 Aug 2024 10:09:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 318AB6B00F4 for ; Thu, 15 Aug 2024 10:09:32 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F070FA166A for ; Thu, 15 Aug 2024 14:09:31 +0000 (UTC) X-FDA: 82454662542.07.6CBA5F7 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf03.hostedemail.com (Postfix) with ESMTP id 00C3520017 for ; Thu, 15 Aug 2024 14:09:29 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rodQTSjR; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of dakr@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dakr@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723730888; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=O6RZya08Q9oUrTLzseJgD5lSQiuNI3eTB2iIl6ZTu08=; b=w/qqTglzwTMCxqBIppzx4K1PWosVLqbCpnooGbv0mcThHnyY//1y4Zho5n1lWDzop20Q3U ePehs0kljyof2od6SFzIHEIC0Ih4Sg6FepgibBopUhnwrfa4JdpJxeKnjg/rUDtvSz8Z4h j0e10lgkn/3N9K1e4AH0K2aaYNxQ6L8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723730888; a=rsa-sha256; cv=none; b=1tMPM2qzuOXCs5l4ZTqzk9BkTMT/xPc9JgrUq3HeE08YhSbGM4k8+1k+XDJL4Gj3QC/qt0 OZAQuI6Zk6y6MyntBvzTYHA2spV3aLRZfq9kHgUWk46Hb8152ygFhEcsA2pir/y6oUhz4z VDhAaRLxQPCL7wwQvKy5i5yxA8ws7go= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rodQTSjR; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf03.hostedemail.com: domain of dakr@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=dakr@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id E91F961E8B; Thu, 15 Aug 2024 14:09:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8DE7C4AF0D; Thu, 15 Aug 2024 14:09:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1723730968; bh=2WMl6EaRKHyEK2/ZQZdr02Mc4qbGm1r0DYQ2zC7R8LE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rodQTSjRyZaZMi9wvpDn6L5vd2PItWpn+1+Hze3ZI6tx7NDN1XGsNH/seMN8chlZe 9fnuYBBvRX+7FPpJwcgzS61CVgHj7TpWsViVSxyWAJfwZv5gTJ1V5BHbnpYInVZ2cF KyOnhrzJApsM5HutwlWg0lYgo+oeuiXznnrPE5JKDqA/IqHGZ5C9r8/zsVBoM8j5vZ MDNtDGgNoV7mA+SHZni/cBBbXo9uJ8w/DzB5Bd50+Js6boJ/M4nOpliwp2rI4EgkBO DrJhnZ34rnCUrCpq547G11cZIXcB/P7ujFG4j9I+pWp1uUxIWIdGm58EIE52f+JgoF S1lapkYIrjUOg== Date: Thu, 15 Aug 2024 16:09:20 +0200 From: Danilo Krummrich To: Benno Lossin Cc: Alice Ryhl , Boqun Feng , ojeda@kernel.org, alex.gaynor@gmail.com, wedsonaf@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, a.hindborg@samsung.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 v5 00/26] Generic `Allocator` support for Rust Message-ID: References: <20240812182355.11641-1-dakr@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 00C3520017 X-Stat-Signature: mdqdbuo8bw7rady1ism6waerc3bbpect X-Rspam-User: X-HE-Tag: 1723730969-470313 X-HE-Meta: U2FsdGVkX18u+3QKBzTFN2jCrsC+Plf5eiaa0IYXyzMNIuequvaFAO1yf8XtQTv7x6zQ7X/A3R+an6KfRLwX9+93QGjCKgNW9nEaqETt0ttlPTaXPAIvLSFC7IsiDE8kemGEARsaqf1fbZFzZjnnFCkrbn1rHijf+hZyqrZbZqX8WsTPm79AL2w8+u1Bdl9xbf091+LF4T4iAClTxWlVTG2e6eb/UeZuhr1F6DQz0o2mzFvfO/fwoifdmDQPvOjeWREUhUYc6SOX0HnyRAYGn93P4urIoO+unynhbsBT1vO98dlhuhxtEP/EgvVWB3bxF8CXqmiWrA3KMUn20BinpEQGctWyAV1a4Xsvi0XpDXXRl+W+jLJAmLa4vGsUp7mVN2wuWMuCRzbveA/qYp2I2qvwvfB7LOuM/1Oo0ZvNpU8mcEBpeK9/Qy65W3pZzt3ASJYo5MNKFpM01cE7iH2v0eaIclO02vpMcx5TCO+plRe7m7+1/xUYcPUhLQD/gXjql16wU0hedH6Gic35CSNAr4egi5y0I+/e5J4jObBBSKZFzIdfpim2JaDr671ahD7IVFQVjOCIFK2USeVSdAJT57jUolVxe1LWxmwDCjog+pw3qnYzCyWe682Wzh4dwBuZv/HMnbObApK9L+EW3FC+OMTxC8tngbRv68PxkciuFcB0BDY5jQq0SMvKUi9RWeSRhpBMc9tVbB3tqWyC4EttNYMMGG/jLt4EU5W60XpnLExFHFp9CgQ9tC7UQi9xmUbdn7vj/C6sMp1ybJe4pFf+eqgDQSXvnrzRENDgyhJ2HkzdbIdhTyvZlAxL+RkPfCOvNb8vpZluNvqqo/2bg2oKJJHelEtSL0oHBuQziLfMd2/ZAx6w5yCSfgRENEs1mJKieV8LMELF+tnF/wj5s02S4iik/JOJ5lstEvB6OLwfpQ4WZqKB1kclH7pMFP0HzhwDYN2JFTbHMCp53QbkMQW Uf5G7rS4 2EQjA1Qb2y6QLGc/HC21E5/YUHVrQdrvNR9VSoilCnwgX2tSB7lNLBiBgFBkjB60Oml+EsoOl8FQNyn/wr/Vpy/5tZzRVZw/m/e0UZHKi5e+7JfJjHWY/TEF8jd4pkaBJCSBv35D7kzAXUTnIObYA5d2vHEykhb1AIKzRKauDhWdthLga90xJwtLdawB4rucU6PZOjq4P9yma5PxqvTxl9U2OBRdhJl3MIkAVZswSSYCyaT55QhwkEqDfdvPJZ31wcj1f8JWtPIq4co2SsD4epM2wMZjlhS3mVoI/XeQqVVEeq5r/Cn7VonOAPAokOc/+NDBJRCmcmrkADCdBeG3AdyRI3gaNAmn0vxHNzeBcmnuG0qC8O+tPXbazJrdqeA0iDWWd 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 Thu, Aug 15, 2024 at 01:39:05PM +0000, Benno Lossin wrote: > On 15.08.24 15:33, Danilo Krummrich wrote: > > On Thu, Aug 15, 2024 at 02:34:50PM +0200, Alice Ryhl wrote: > >> On Thu, Aug 15, 2024 at 2:33 PM Danilo Krummrich wrote: > >>> > >>> On Thu, Aug 15, 2024 at 11:20:32AM +0200, Alice Ryhl wrote: > >>>> On Thu, Aug 15, 2024 at 4:52 AM Danilo Krummrich wrote: > >>>>> > >>>>> On Wed, Aug 14, 2024 at 12:32:15PM -0700, Boqun Feng wrote: > >>>>>> Hi Danilo, > >>>>>> > >>>>>> I'm trying to put your series on rust-dev, but I hit a few conflicts due > >>>>>> to the conflict with `Box::drop_contents`, which has been in rust-dev > >>>>>> for a while. And the conflict is not that trivial for me to resolve. > >>>>>> So just a head-up, that's a requirement for me to put it on rust-dev for > >>>>>> more tests from my end ;-) > >>>>> > >>>>> I rebased everything and you can fetch them from [1]. > >>>>> > >>>>> I resolved the following conflicts: > >>>>> > >>>>> - for `Box`, implement > >>>>> - `drop_contents` > >>>>> - `manually_drop_contents` [2] > >>>> > >>>> Not sure I like this name. It sounds like something that runs the > >>>> destructor, but it does the exact opposite. > >>> > >>> I thought it kinda makes sense, since it's analogous to `ManuallyDrop::new`. > >>> > >>> What about `Box::forget_contents` instead? > >> > >> One option is `into_manually_drop`. This uses the convention of using > >> the `into_*` prefix for conversions that take ownership of the > >> original value. > > > > The signature of the current `Box::manually_drop_contents` is the same as for > > `Box::drop_contents`, namely > > `fn manually_drop_contents(this: Self) -> Box, A>`. > > > > `into_manually_drop` seems misleading for for returning a > > `Box, A>`. > > > > I still think `forget_contents` hits it quite well. Just as `drop_contents` > > drops the value, `forget_contents` makes the `Box` forget the value. > > I think `forget_contents` sounds good. Can you please add some more docs > to that function though? Like an example and change "Manually drops the > contents, but keeps the allocation" to "Forgets the contents (does not > run the destructor), but keeps the allocation.". I can't really think of a good real world example other than moving out of a `Box`, can you? Otherwise, maybe it just shouldn't be public? > > Another thing that I spotted while looking at the patch, `move_out` > doesn't need the `transmute_copy`, you should be able to just call > `read` on the pointer. While technically it's the same I thought `transmute_copy` is considered better, since it has less stict safety requirements? For `transmute_copy` we only need to say, that dst has the same type as src, whereas for `read` the pointer must be valid for reads, properly aligned and point to an initialized value. > > --- > Cheers, > Benno >