From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (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 3BDD92FFDF7 for ; Wed, 26 Nov 2025 09:50:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764150652; cv=none; b=Thy82MmtiSx8yaw6LAqJT35PD4L7ogstYL4M0q3CIOoPMI2Ol52MyznWMjkManfATxeRy/q/tMjoe5mwUUvzpym1wGyu7yvKOjm7azU07nOn5VL8hpUEvZFFOENdT+BRty62VyGpIq01t0U1Flo71SlSOkmLt3mfsyN6FEqIpkA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764150652; c=relaxed/simple; bh=E/RU1dhL7sHkXwY6wCpifQdBufsgzqGxIPaX5zPDkrA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tv38bV/TvxLwO8FFqZCFhFKKdWm/tyIGsFwNIH7Kh2gL5kqkwwCIHoirhz5VnH3JtSWJs8uAGmiu6Ztt0bDEgSUgdWzxSbiPCMr8reils2jVg5lbYMxHt7dV9SduekOAP9AJPu+Tlj6xzHuEZa5TNXrOhr9kc+qnU6DQSKw8fEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GKV0l3OR; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GKV0l3OR" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-40cfb98eddbso235686f8f.0 for ; Wed, 26 Nov 2025 01:50:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1764150646; x=1764755446; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=jSvzj95/YOMgXX2WrYYsc8VQubWjVbTM1tYJZOPIebA=; b=GKV0l3ORf0zahec9/CeZZJhBSUxshL4seiMyY3dvKuImJJWX7Ytx3GETkxeYtNt5OB GxIMCIoD8olQ92i3Ry0QtwsIimAsV2ciziioIGM0kghNKnRA0TUPT1RPU4nRuKl/3QIl PycoN7ZXbesNDLnE3YbzW6dTOPcSrI91BRAsW3epYYvciR/4AcB4lYd0eUGXT3EtLH2W L+XFdv7hgccDI1W/8ldn6jNNN9YPah1X8Cwkqb7kUzYJC+8nw6aUxM5tnWLzi8UoiuQm +cVOPs34KkSvRHby1hTihLWUdaS+BIQ/+wFfNvZSXYlAUstdfIVfDP7VhffdzY9f5QBO Ejug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764150646; x=1764755446; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=jSvzj95/YOMgXX2WrYYsc8VQubWjVbTM1tYJZOPIebA=; b=goUvSfZPqbJdpo8pLeKLuuIY5I9P5a1hrjWWnnpOeAJzsaO+ckqocnvqg+cj8Sh+As qfySPViB+RGnZchzLvjFzqMGJ+VSWVxwL2VFO6tBY2R3kY98id+Uyocnn7YCdR0tNF8V 6gvBgc6bP+01F/+xbGJqajfZnHaOzH+4vMA/iQMiJSsrlK8PEQLDvz0H8MYI59+IJZMn LJuB/IU2Y33ei/HNi1O1MpPL7FsF2eu4qr/biHrctvBUIbvqRv8cQxbXu+JEXrPGHdNI W6/OokcjRvqURWBxRgaYznDKpynp+wTzwNuFc+o9y4l4SwPiydAZ/yEHPzSpjqBxmpsR PcLQ== X-Forwarded-Encrypted: i=1; AJvYcCVeERc1rgxDwblzVpQHJQcsj12iCsjYDsOH5I5zzm28tFR7N+jJYiUWRzh4D2sPIQQoe0sQmVi0dqioWKZxJw==@vger.kernel.org X-Gm-Message-State: AOJu0YxvvZ+wH+FU6zivnRCU34juuVT0fgNl+e/saYHBVqiwD2OUaStn FwLVkiingauSzSF856d+isfJy2o9iUDDckhwRGz/7cqaiXyhsjzLjmFCRpcSZ3lYF4JrUOhhxLl kthEzJ+UEPkdzjv+UhA== X-Google-Smtp-Source: AGHT+IEqNy6XkLEGvnBrcIM1oqNkFhyCHgbUhLMFwOhqN/xcPMxU4ziKwD306VJn7O/813l4Ug2PbJ6oZFBRHDE= X-Received: from wmdn1.prod.google.com ([2002:a05:600c:2941:b0:477:103e:8e30]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:4eca:b0:46f:a2ba:581f with SMTP id 5b1f17b1804b1-477c0540a68mr204945775e9.16.1764150646449; Wed, 26 Nov 2025 01:50:46 -0800 (PST) Date: Wed, 26 Nov 2025 09:50:45 +0000 In-Reply-To: Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20251119112117.116979-1-zhiw@nvidia.com> <20251119112117.116979-4-zhiw@nvidia.com> Message-ID: Subject: Re: [PATCH v7 3/6] rust: io: factor common I/O helpers into Io trait From: Alice Ryhl To: Alexandre Courbot Cc: Zhi Wang , rust-for-linux@vger.kernel.org, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, dakr@kernel.org, bhelgaas@google.com, kwilczynski@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, lossin@kernel.org, a.hindborg@kernel.org, tmgross@umich.edu, markus.probst@posteo.de, helgaas@kernel.org, cjia@nvidia.com, smitra@nvidia.com, ankita@nvidia.com, aniketa@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com, joelagnelf@nvidia.com, jhubbard@nvidia.com, zhiwang@kernel.org Content-Type: text/plain; charset="utf-8" On Wed, Nov 26, 2025 at 04:52:05PM +0900, Alexandre Courbot wrote: > On Tue Nov 25, 2025 at 11:58 PM JST, Alice Ryhl wrote: > > On Tue, Nov 25, 2025 at 10:44:29PM +0900, Alexandre Courbot wrote: > >> On Fri Nov 21, 2025 at 11:20 PM JST, Alice Ryhl wrote: > >> > On Wed, Nov 19, 2025 at 01:21:13PM +0200, Zhi Wang wrote: > >> >> The previous Io type combined both the generic I/O access helpers > >> >> and MMIO implementation details in a single struct. > >> >> > >> >> To establish a cleaner layering between the I/O interface and its concrete > >> >> backends, paving the way for supporting additional I/O mechanisms in the > >> >> future, Io need to be factored. > >> >> > >> >> Factor the common helpers into new {Io, Io64} traits, and move the > >> >> MMIO-specific logic into a dedicated Mmio type implementing that > >> >> trait. Rename the IoRaw to MmioRaw and update the bus MMIO implementations > >> >> to use MmioRaw. > >> >> > >> >> No functional change intended. > >> >> > >> >> Cc: Alexandre Courbot > >> >> Cc: Alice Ryhl > >> >> Cc: Bjorn Helgaas > >> >> Cc: Danilo Krummrich > >> >> Cc: John Hubbard > >> >> Signed-off-by: Zhi Wang > >> > > >> > I said this on a previous version, but I still don't buy the split > >> > into IoFallible and IoInfallible. > >> > > >> > For one, we're never going to have a method that can accept any Io - we > >> > will always want to accept either IoInfallible or IoFallible, so the > >> > base Io trait serves no purpose. > >> > > >> > For another, the docs explain that the distinction between them is > >> > whether the bounds check is done at compile-time or runtime. That is not > >> > the kind of capability one normally uses different traits to distinguish > >> > between. It makes sense to have additional traits to distinguish > >> > between e.g.: > >> > > >> > * Whether IO ops can fail for reasons *other* than bounds checks. > >> > * Whether 64-bit IO ops are possible. > >> > > >> > Well ... I guess one could distinguish between whether it's possible to > >> > check bounds at compile-time at all. But if you can check them at > >> > compile-time, it should always be possible to check at runtime too, so > >> > one should be a sub-trait of the other if you want to distinguish > >> > them. (And then a trait name of KnownSizeIo would be more idiomatic.) > >> > > >> > And I'm not really convinced that the current compile-time checked > >> > traits are a good idea at all. See: > >> > https://lore.kernel.org/all/DEEEZRYSYSS0.28PPK371D100F@nvidia.com/ > >> > > >> > If we want to have a compile-time checked trait, then the idiomatic way > >> > to do that in Rust would be to have a new integer type that's guaranteed > >> > to only contain integers <= the size. For example, the Bounded integer > >> > being added elsewhere. > >> > >> Would that be so different from using an associated const value though? > >> IIUC the bounded integer type would play the same role, only slightly > >> differently - by that I mean that if the offset is expressed by an > >> expression that is not const (such as an indexed access), then the > >> bounded integer still needs to rely on `build_assert` to be built. > > > > I mean something like this: > > > > trait Io { > > const SIZE: usize; > > fn write(&mut self, i: Bounded); > > } > > I have experimented a bit with this idea, and unfortunately expressing > `Bounded` requires the generic_const_exprs feature and is > not doable as of today. > > Bounding an integer with an upper/lower bound also proves to be more > demanding than the current `Bounded` design. For the `MIN` and `MAX` > constants must be of the same type as the wrapped `T` type, which again > makes rustc unhappy ("the type of const parameters must not depend on > other generic parameters"). A workaround would be to use a macro to > define individual types for each integer type we want to support - or to > just limit this to `usize`. > > But the requirement for generic_const_exprs makes this a non-starter I'm > afraid. :/ Can you try this? trait Io { type IdxInt: Int; fn write(&mut self, i: Self::IdxInt); } then implementers would write: impl Io for MyIo { type IdxInt = Bounded<17>; } instead of: impl Io for MyIo { const SIZE = 17; } Alice