From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f43.google.com (mail-pj1-f43.google.com [209.85.216.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4664E3B2FD4 for ; Mon, 29 Jun 2026 11:17:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782731824; cv=none; b=iWfl8oXEyiV2XkkMu0K/2T3ZaMpOH7l3s8crU2FkYMP3+aSo2Z4NNNTucIishYwXkuxynHMythtd1buUrkqGsdLHfYP4oM6q0cEJmqI8q301oOss3jDLk9dWx7+ire75xydPcmFFXSiA4DdL72gZYepQjFbuZZpd4+rJYtj2rV8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782731824; c=relaxed/simple; bh=eXKifjwGmgyNkfNyz4AW5WzTlql2ov9lymuZ6YjJItM=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=WA0ZOG2oPbFsT8H86XzsF9DGhbTeSHUxO7kuh2R0ipYMaOIiUdhn5qg/GfTVlD9XLEsieKQD95Hxumk970oPL9g67hzKRW2JUo9ly88l9p2G5/C0PVuopuEMPZyHcj33YosnLlclGuyweM9twHiSrmFKEi7Csl8JaXgGlBWYT6A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Z8yud0QA; arc=none smtp.client-ip=209.85.216.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Z8yud0QA" Received: by mail-pj1-f43.google.com with SMTP id 98e67ed59e1d1-37f72212544so2647913a91.0 for ; Mon, 29 Jun 2026 04:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782731822; x=1783336622; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=sf9modGDEu51qoKMDfa6F2dR4atoz1mf0fTmi7rEwIc=; b=Z8yud0QAYGzTRcOp/qtfnqTIy06lXcmiWSS4F2c8vSJ+bEGZyba5nT7YfrMnBJ1kse H5CG/3Ct8FPm86B49i3cTYRcm9uJtZvLjYGMjlCk+WgdE2oecL+z/PGF2qeC509LK1Y8 cSUy36WCtaXjdk7hnNeWNSINIRcsxPBzZAp7Usuh94NXDo8cVc95hU5T6YvrufQAMiZ9 boGbEoOv1G8afUd67r/P3BXLpxHVLeR2sj6QxqTIX69Na5kRdRG/uOohPdvFxeZWKWkA EgwXbIMr4BboRfv0rO8ZrZ0Lrw+Qbhumfs9rJ41uEzuz5oQvqP9pwyzRb+C4zt53ypcs l0Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782731822; x=1783336622; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=sf9modGDEu51qoKMDfa6F2dR4atoz1mf0fTmi7rEwIc=; b=O9KcGLOPEIi/5noSBjzRIxbTiGm6FiIzZcbi48R/dxstt0IEU1bQG1UeiNM3h9EE4R Vvblc3KAT5du99vsmdn83slTdTYNEwBJS5slO/fHOfBjRaEs4zsnO24+f2H148JAHuup kLlgzg3HQAtFPp2a/k21Mk+rQDUnVC8TWW1LOvCPOiv6Gc6TFzOqjNrQe0Ji+kp1EJrb Ek47t1IERMBIhHarw5qiNtdxF+leyj2ntcXr5X+CvE0gb00hrHo1uvWIRnqvlXlKX0nN 1RmeZK4hQGxMsPKy3JpFJDzUVrD4RgzLc/VLYuP91mf7k8/ZvtMqIroezMWBI6vxB0Q1 6VnA== X-Forwarded-Encrypted: i=1; AHgh+Rq8rmqC9J9lbQh3I/Xhv+KLcQKfJBFQlAJEhv5IiilXcA2+iLggHnyR0e1ord2klbU70cf1vF37L0bhXoc=@vger.kernel.org X-Gm-Message-State: AOJu0Yxb9/idLradDTSgTtktJSB9UAZ4c1d1GItQBCWPl+JTuSWkS+Zb AK//M4SzLgv99dMjM4K36zX89O9hW9R5HNN/Dm0i62KjVHD0JjQ5FpCS X-Gm-Gg: AfdE7clGW8Dt6X0+sVkGZaKVhhJwbDnmYXxu+0yoDin30iwjI+hBCjWVvrkwkoCtHMM u1tsHp8MN/9clCPWCEbKAzRTzSvgG/3Sh1Pvuzz/DrZwvEFPj4++hro6RFKu5si5bFR4YMrMIVO NlbkOKTl/7hkRvkLeWA2GZ9v0wID6daqrfNfG3iT9VOkk3zmVf4t4sI6Gacpr4ydz1G8kGvcHYV /Ghepc6H5IZaD0MY7k/EXsG1Qbwd1+i9VcfY1sYzrOPnY4fcKBpmZ9JNsT5nNxcAFOzHtzLVuH/ aGhjHLyDEJfIGB9ZzrzhAU6hC3fEqRqQLzAV08h7i+vwy1LtgkI9bjOXcVpGDIP5beIdF2t+8H3 7tNYFjHnodt4DMSld9ZNU6TOlNT/nVDk+QUXxs8XKcQF69lTeD2gL9EJ29Pgdz4Y0rSHTZCFNRt otXg6kMIS9SeoEk1jzDgTV4+y7yRa4WSKa+wHU25fmjS4rSjLcLqgEjfd5XjPHF3V11hV122JsL PCxlz2/h5InZfpd4q5CuZTKbOnWzqGXFmuKVikp X-Received: by 2002:a17:90b:5830:b0:380:38d2:80bb with SMTP id 98e67ed59e1d1-38038d2824cmr453534a91.8.1782731822431; Mon, 29 Jun 2026 04:17:02 -0700 (PDT) Received: from localhost ([143.248.188.236]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2c7f5ac7c9asm91594835ad.4.2026.06.29.04.16.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 29 Jun 2026 04:17:02 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 29 Jun 2026 11:16:56 +0000 Message-Id: Cc: , "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Danilo Krummrich" , "Daniel Almeida" , "Tamir Duberstein" , =?utf-8?q?Onur_=C3=96zkan?= , "David Airlie" , "Simona Vetter" , , , , Subject: Re: [PATCH RFC 0/4] rust: dma: bridge zerocopy-derived types into the transmute byte-safety bound From: "SeungJong Ha" To: "Alexandre Courbot" , "SeungJong Ha via B4 Relay" X-Mailer: aerc 0.21.0 References: <20260628-dma-zerocopy-bridge-v1-0-9a2895ebe30d@gmail.com> In-Reply-To: On Mon Jun 29, 2026 at 7:17 AM UTC, Alexandre Courbot wrote: > On Mon Jun 29, 2026 at 2:10 AM JST, SeungJong Ha via B4 Relay wrote: >> DMA-coherent allocations (CoherentAllocation/Coherent/dma::Pool) bound >> their element type on kernel::transmute::{AsBytes, FromBytes}. This RFC >> lets a type satisfy that bound by deriving zerocopy's byte-safety traits >> instead of a hand-written unsafe impl. >> >> The bound cannot be switched to zerocopy wholesale (some DMA structs are >> unions that IntoBytes cannot derive), and a blanket bridge impl is >> rejected by coherence. So the series bridges the two per type: >> >> 1. add the bridge macro impl_transmute_via_zerocopy!, which emits the >> transmute impls only for a zerocopy-derived type. >> 2. re-export zerocopy::Immutable from the prelude. >> 3-4. worked example: convert nova-core's GspMem and msgq POD types. > > Can you give more details about what the macro is for? My understanding > is that it is a temporary fix for the generated bindings; if so, I'd > prefer to apply a definitive solution (like using > `#[derive(zerocopy_derive::most_traits)]`, or updating the bindings > generator tool) rather than something that will be removed later. This macro is giving safe manual derive from zercopy traits to transmute. However, it is not necessary if the transmute is going to be fully replaced with zerocopy. I found it seems to be true [1]. > But intuitively I'd say that we can (and should) probably do without > this intermediate step. But please let me know if there is something I > missed. I agree. The only useful parts remain in this RFC patch is explicit padding in GspMem. AFAIK it is still necessary after the auto derivaiton of `most_traits`. Best Regards SeungJong [1] https://lore.kernel.org/all/DJLEHDNJCUD0.38PFZ5773D6BX@kernel.org/