exporting a device type

exporting a device type

[Andy Shevchenko]

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).

-- 
With Best Regards,
Andy Shevchenko

Re: exporting a device type

[Danilo Krummrich]

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].

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.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?h=for-driver-core&id=d72c42c1da4149fec28e3b180654bf5fd88c2094

Re: exporting a device type

[Andy Shevchenko]

On Sat, Apr 12, 2025 at 12:25 AM Danilo Krummrich <dakr@kernel.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.

> 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!

> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/dakr/linux.git/commit/?h=for-driver-core&id=d72c42c1da4149fec28e3b180654bf5fd88c2094



-- 
With Best Regards,
Andy Shevchenko

Re: exporting a device type

[Danilo Krummrich]

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@kernel.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/