lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025070329-ream-arrogance-0737@gregkh>
Date: Thu, 3 Jul 2025 17:06:44 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Danilo Krummrich <dakr@...nel.org>
Cc: rafael@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com,
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
	benno.lossin@...ton.me, a.hindborg@...nel.org, aliceryhl@...gle.com,
	tmgross@...ch.edu, david.m.ertman@...el.com, ira.weiny@...el.com,
	leon@...nel.org, kwilczynski@...nel.org, bhelgaas@...gle.com,
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH 1/8] rust: device: introduce device::Internal

On Tue, Jul 01, 2025 at 02:32:48PM +0200, Danilo Krummrich wrote:
> On Tue, Jul 01, 2025 at 12:41:53PM +0200, Danilo Krummrich wrote:
> > On Tue, Jul 01, 2025 at 11:26:47AM +0200, Greg KH wrote:
> > > On Sat, Jun 21, 2025 at 09:43:27PM +0200, Danilo Krummrich wrote:
> > > > Introduce an internal device context, which is semantically equivalent
> > > > to the Core device context, but reserved for bus abstractions.
> > > > 
> > > > This allows implementing methods for the Device type, which are limited
> > > > to be used within the core context of bus abstractions, i.e. restrict
> > > > the availability for drivers.
> > > > 
> > > > Signed-off-by: Danilo Krummrich <dakr@...nel.org>
> > > > ---
> > > >  rust/kernel/device.rs | 14 ++++++++++++++
> > > >  1 file changed, 14 insertions(+)
> > > > 
> > > > diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
> > > > index 665f5ceadecc..e9094d8322d5 100644
> > > > --- a/rust/kernel/device.rs
> > > > +++ b/rust/kernel/device.rs
> > > > @@ -261,6 +261,10 @@ pub trait DeviceContext: private::Sealed {}
> > > >  /// any of the bus callbacks, such as `probe()`.
> > > >  pub struct Core;
> > > >  
> > > > +/// Semantically the same as [`Core`] but reserved for internal usage of the corresponding bus
> > > > +/// abstraction.
> > > > +pub struct Internal;
> > > 
> > > Naming is hard :)
> > > 
> > > As this is ONLY for the bus code to touch, why not call it Bus_Internal?
> > 
> > BusInternal is better indeed!
> 
> I now remember that I first wanted to go for CoreInternal, but then went for
> just Internal, since it thought it was unnecessary to be more specific. But I
> now think CoreInternal would have been the correct pick.

Thanks for the long explainations that helped out a lot.  As I said on
chat earlier, I agree with you now.  Can you respin this with
CoreInternal and we can queue it up?

Worst thing that happens is the api doesn't work out and we rework it
based on real users :)

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ