linux-kernel - Re: exporting a device type

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] [day] [month] [year] [list]

Message-ID: <Z_q0iRXjPbdQvHMu@cassiopeiae>
Date: Sat, 12 Apr 2025 20:44:25 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: exporting a device type

On Sat, Apr 12, 2025 at 08:56:39PM +0300, Andy Shevchenko wrote:
> On Sat, Apr 12, 2025 at 12:25 AM Danilo Krummrich <dakr@...nel.org> wrote:
> > On Fri, Apr 11, 2025 at 10:39:38PM +0300, Andy Shevchenko wrote:
> > > I have an issue with this change
> > >
> > > https://web.git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?h=for-driver-core&id=e86cc69186051d7312711565803de586efd9b2cf
> > >
> > > (I think you haven't yet sent it for review, so this is just
> > > preliminary look at)
> > >
> > > The idea of exporting bus type will open a non-reversible box of
> > > changes when people will start abusing it. Instead just provide an API
> > > dev_is_auxiliary() as it's done in other subsystems (yes, I know that
> > > some of them are still exporting the type, but it's most likely due to
> > > historical reasons of not thinking through it at that time).
> >
> > Yeah, most busses export it and provide a dev_is_*() macro, which we can't use
> > in Rust. That's why for PCI and platform I started using the bus type directly,
> > see e.g. [1].
> 
> I know. When I tried to do the same for PNP devices, Greg and others
> were objecting to this. An auxiliary bus is a new thing and I don't
> believe that Greg or any other kernel developer who is generally in
> favour of Rust development will accept this particular change.

Greg and me are aligned on this in the context of having Rust implement TryFrom
for device "upcasts" [1]. However, I decided to drop it for the auxiliary bus
for now, since I think there won't be an immediate use-case for the auxiliary
bus.

> > However, I already considered changing it up by just creating Rust helper
> > functions for the dev_is_*() macros and provide a dev_is_auxiliary() API
> > instead. This also simplifies things a bit and gets me rid of the
> > Device::bus_type_raw() helper.
> 
> This would be wonderful!

For PCI and platform I already switched to helper functions for the dev_is_*()
macros. For auxiliary, as mentioned above, I will drop it for now.

[1] https://lore.kernel.org/lkml/2025032455-elk-whoops-3439@gregkh/