From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (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 80D6323E35F for ; Sun, 10 Aug 2025 14:46:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754837172; cv=none; b=UPcRvQBqPgRaLcChG4OFhTSWopDZJ4BAeA73jQ2j0vLkSyNrRaKgT6Wipo6nZlWGmAj3mAtNgWZ7ZPR97iuegeJoh4b2yJ7RhZmHjK1UXqZEUOF+nyMUIJaqruCEPlBSZjke4oDylhJh8z4n225PV5tIY+H1oqRablNu4tJlOdY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754837172; c=relaxed/simple; bh=yNCyjBxmpcqjd9BVhKaOCkQW4cIXOHRPMXQ4R74Lndg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=AbbC3nARZTKb2sBifrR2slLOcvrxzFusCuLZcad4hPoDBAxxc+CJQby2qSuD3l5HpfWZmItLdo8O/FiM1idkyjIeMu6lQ1bK/cRwknYXH9yFHBSq6moM2lrnAQQtN7EOS3xeDG8X/Ca9gOj3HP7/wWjK0Ms48ma5eiFoDG465hs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=furiosa.ai; spf=none smtp.mailfrom=furiosa.ai; dkim=pass (1024-bit key) header.d=furiosa.ai header.i=@furiosa.ai header.b=LFYakjWM; arc=none smtp.client-ip=209.85.215.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=furiosa.ai Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=furiosa.ai Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=furiosa.ai header.i=@furiosa.ai header.b="LFYakjWM" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-b4239091facso2639214a12.0 for ; Sun, 10 Aug 2025 07:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=furiosa.ai; s=google; t=1754837171; x=1755441971; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=+ofUuggQi14oNkJwPEJoW3BcLCOFwOPlMFxB7Ion1Fc=; b=LFYakjWMx618KlHyUcHLhKrWznyapA7jk37TtwJjF6G6JTG37Pn0iqGK2dvAHiGlLN mqX+zyycCs5XDqXObntZ7svkNITyMm+2GvsGKYUzEPDmvLZvCfKb8Q68yw5AZhTkxp0C ftfp/EB5w7CsgddOxualANUZ5TXwbbuaX1GE0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754837171; x=1755441971; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+ofUuggQi14oNkJwPEJoW3BcLCOFwOPlMFxB7Ion1Fc=; b=UBOQW/z2XCGaO5TUnV1QcH3EdUd5DvB0v7Yq4/lyVfT8B5oBW5q2c0zKQK//XqiLUs 3JngZb2togBRBasrvhvUsqL1SLGmIpBkinTnhLZmY+roxSy8DKh5oFO6yQf36Q3eK9JH xsoDoLkAMfdDKvm9py//KbcWKVPkek/OcV2we++EA4Ozwa2XMK+gCnr4dZS4IzOLKYEd RqOqgEQUxYdAp9270Rx321ELr8tGwy8mJgJ+gPnp+wsYHKr3cR1/P7Hu8U9Dersp/0Xb dqSlskK356vQIsWHnFKo8OarhXWcNZBfxjP7q0Dx334ajm7KmkwS82Xh1BXmLBmhJg4Y TFcQ== X-Forwarded-Encrypted: i=1; AJvYcCWo0HpHbLYbvzJP62a5EPMN6a1aklN62NVPy9GI5RIWQZv7e4FPC5+pIU2ojT3eXBGTXBYGkoa5IsFe6N9o8g==@vger.kernel.org X-Gm-Message-State: AOJu0YyRlPWiyCWhtxqRP7gvD9GmMMl+FKSmQ9hlXXsbfIM3QR4TSdU4 WbY0dPqTrEGqanVNeCrOInbSs8ivTouY6SIdnTiFZqE/Fp5l4EQm4HiLc5yUooE7dXc= X-Gm-Gg: ASbGncv3fscI5PBqtBHwdLp8tXGz4XJC+URRwEZLPsd8tG0S6jBeQkNx9P1Ul0UodzT RH+Kq4bFmZRbBxUnPoHl4wklTQ4YJ0iEksfqbU2aXwhT5SewwR7DNxKBmVXCSsvF6HPrg3y4cwq xUmRfOYqOP6EqSr7rwJamJ91qxMJ4GKC23csUZ9msA6hY0MfF3/vorYwc19/La/MQZub3Ecfvme E26V/zXipRrlhvc25Ed/sqoLE3aqZszEEwgtyKmjY3WyKAkr7Q44P8F91DzspUw30xGAtSojS4V XmUbOjQuBsbe77/FWefcPidi/AJj7YPWzZUlUXjoJIadlTrwiY8SAn/VnqWuKluaukaPdzNvx3n so1cKptfbLtpef6aElJUitdrnMFTNC5tm7vDI3NOhvUOcCo6ZgxfpQvET X-Google-Smtp-Source: AGHT+IGA/VW29LBb6c+SvCc/Xi2z36iu+jzINihApT/PsLqokoe8h/QSSjwto30OM6bfQFyw31ARWA== X-Received: by 2002:a17:902:cec8:b0:242:9bbc:6018 with SMTP id d9443c01a7336-242c2277f70mr138091215ad.56.1754837170576; Sun, 10 Aug 2025 07:46:10 -0700 (PDT) Received: from sidongui-MacBookPro.local ([175.195.128.78]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-241d1ef75bdsm250934735ad.11.2025.08.10.07.46.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 10 Aug 2025 07:46:10 -0700 (PDT) Date: Sun, 10 Aug 2025 23:46:05 +0900 From: Sidong Yang To: Daniel Almeida Cc: Benno Lossin , Caleb Sander Mateos , Miguel Ojeda , Arnd Bergmann , Jens Axboe , Greg Kroah-Hartman , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, io-uring@vger.kernel.org Subject: Re: [RFC PATCH v2 2/4] rust: io_uring: introduce rust abstraction for io-uring cmd Message-ID: References: <949A27C5-1535-48D1-BE7E-F7E366A49A52@collabora.com> <81C84BD8-D99C-4103-A280-CFC71DF58E3B@collabora.com> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <81C84BD8-D99C-4103-A280-CFC71DF58E3B@collabora.com> On Sun, Aug 10, 2025 at 11:27:12AM -0300, Daniel Almeida wrote: > > > > On 10 Aug 2025, at 10:50, Sidong Yang wrote: > > > > On Sat, Aug 09, 2025 at 10:22:06PM +0200, Benno Lossin wrote: > >> On Sat Aug 9, 2025 at 2:51 PM CEST, Sidong Yang wrote: > >>> On Sat, Aug 09, 2025 at 12:18:49PM +0200, Benno Lossin wrote: > >>>> We'd need to ensure that `borrow_pdu` can only be called if `store_pdu` > >>>> has been called before. Is there any way we can just ensure that pdu is > >>>> always initialized? Like a callback that's called once, before the value > >>>> is used at all? > >>> > >>> I've thought about this. As Celab said, returning `&mut MaybeUninit<[u8;32]> is > >>> simple and best. Only driver knows it's initialized. There is no way to > >>> check whether it's initialized with reading the pdu. The best way is to return > >>> `&mut MaybeUninit<[u8;32]>` and driver initializes it in first time. After > >>> init, driver knows it's guranteed that it's initialized so it could call > >>> `assume_init_mut()`. And casting to other struct is another problem. The driver > >>> is responsible for determining how to interpret the PDU, whether by using it > >>> directly as a byte array or by performing an unsafe cast to another struct. > >> > >> But then drivers will have to use `unsafe` & possibly cast the slice to > >> a struct? I think that's bad design since we try to avoid unsafe code in > >> drivers as much as possible. Couldn't we try to ensure from the > >> abstraction side that any time you create such an object, the driver > >> needs to provide the pdu data? Or we could make it implement `Default` > >> and then set it to that before handing it to the driver. > > > > pdu data is [u8; 32] memory space that driver can borrow. this has two kind of > > issues. The one is that the array is not initialized and another one is it's > > array type that driver should cast it to private data structure unsafely. > > The first one could be resolved with returning `&mut MaybeUninit<>`. And the > > second one, casting issue, is remaining. > > > > It seems that we need new unsafe trait like below: > > > > /// Pdu should be... repr C or transparent, sizeof <= 20 > > unsafe trait Pdu: Sized {} > > > > /// Returning to casted Pdu type T > > pub fn pdu(&mut self) -> &mut MaybeUninit > > Wait, you receive an uninitialized array, and you´re supposed to cast it to > T, is that correct? Because that does not fit the signature above. Sorry if my intent wasn´t clear. More example below: // in rust/kernel/io_uring.rs unsafe trait Pdu: Sized {} pub fn pdu(&mut self) -> &mut MaybeUninit { let inner = unsafe { &mut *self.inner.get() }; let ptr = &raw mut inner.pdu as *mut MaybeUninit; // the cast here unsafe { &mut *ptr } } // in driver code #[repr(C)] struct MyPdu { value: u64 } unsafe impl Pdu for MyPdu {} // initialize ioucmd.pdu().write(MyPdu { value: 1 }); // read or modify let mypdu = unsafe { ioucmd.pdu().assume_init_mut() }; Thanks, Sidong > > > > > I think it is like bytemuck::Pod trait. Pod meaning plain old data. > > > > Thanks, > > Sidong > > > > > >> > >> --- > >> Cheers, > >> Benno > > > I'm not really sure how this solves the transmute/cast problem. Is the trait > you're referring to supposed to have any member functions? Or is it just a > marker trait? > > I wonder if we can fit the existing "kernel::FromBytes" for this problem. > > - Daniel >