From: Danilo Krummrich <dakr@kernel.org>
To: Dirk Behme <dirk.behme@de.bosch.com>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org,
bhelgaas@google.com, ojeda@kernel.org, alex.gaynor@gmail.com,
boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com,
benno.lossin@proton.me, tmgross@umich.edu,
a.hindborg@samsung.com, aliceryhl@google.com, airlied@gmail.com,
fujita.tomonori@gmail.com, lina@asahilina.net,
pstanner@redhat.com, ajanulgu@redhat.com, lyude@redhat.com,
robh@kernel.org, daniel.almeida@collabora.com,
saravanak@google.com, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH v3 15/16] rust: platform: add basic platform device / driver abstractions
Date: Tue, 29 Oct 2024 10:50:02 +0100 [thread overview]
Message-ID: <ZyCvyrb5jsY1O4uX@pollux> (raw)
In-Reply-To: <8d72e37e-9e27-4857-b0eb-0b1e98cc5610@de.bosch.com>
On Tue, Oct 29, 2024 at 10:19:08AM +0100, Dirk Behme wrote:
> On 29.10.2024 09:50, Danilo Krummrich wrote:
> > On Tue, Oct 29, 2024 at 08:20:55AM +0100, Dirk Behme wrote:
> > > On 28.10.2024 11:19, Danilo Krummrich wrote:
> > > > On Thu, Oct 24, 2024 at 11:11:50AM +0200, Dirk Behme wrote:
> > > > > > +/// IdTable type for platform drivers.
> > > > > > +pub type IdTable<T> = &'static dyn kernel::device_id::IdTable<of::DeviceId, T>;
> > > > > > +
> > > > > > +/// The platform driver trait.
> > > > > > +///
> > > > > > +/// # Example
> > > > > > +///
> > > > > > +///```
> > > > > > +/// # use kernel::{bindings, c_str, of, platform};
> > > > > > +///
> > > > > > +/// struct MyDriver;
> > > > > > +///
> > > > > > +/// kernel::of_device_table!(
> > > > > > +/// OF_TABLE,
> > > > > > +/// MODULE_OF_TABLE,
> > > > >
> > > > > It looks to me that OF_TABLE and MODULE_OF_TABLE are quite generic names
> > > > > used here. Shouldn't they be somehow driver specific, e.g. OF_TABLE_MYDRIVER
> > > > > and MODULE_OF_TABLE_MYDRIVER or whatever? Same for the other
> > > > > examples/samples in this patch series. Found that while using the *same*
> > > > > somewhere else ;)
> > > >
> > > > I think the names by themselves are fine. They're local to the module. However,
> > > > we stringify `OF_TABLE` in `module_device_table` to build the export name, i.e.
> > > > "__mod_of__OF_TABLE_device_table". Hence the potential duplicate symbols.
> > > >
> > > > I think we somehow need to build the module name into the symbol name as well.
> > >
> > > Something like this?
> >
> > No, I think we should just encode the Rust module name / path, which should make
> > this a unique symbol name.
> >
> > diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs
> > index 5b1329fba528..63e81ec2d6fd 100644
> > --- a/rust/kernel/device_id.rs
> > +++ b/rust/kernel/device_id.rs
> > @@ -154,7 +154,7 @@ macro_rules! module_device_table {
> > ($table_type: literal, $module_table_name:ident, $table_name:ident) => {
> > #[rustfmt::skip]
> > #[export_name =
> > - concat!("__mod_", $table_type, "__", stringify!($table_name), "_device_table")
> > + concat!("__mod_", $table_type, "__", module_path!(), "_", stringify!($table_name), "_device_table")
> > ]
> > static $module_table_name: [core::mem::MaybeUninit<u8>; $table_name.raw_ids().size()] =
> > unsafe { core::mem::transmute_copy($table_name.raw_ids()) };
> >
> > For the doctests for instance this
> >
> > "__mod_of__OF_TABLE_device_table"
> >
> > becomes
> >
> > "__mod_of__doctests_kernel_generated_OF_TABLE_device_table".
>
>
> What implies *one* OF/PCI_TABLE per path (file)?
No, you can still have as many as you want for the same file, you just have to
give them different identifier names -- you can't have two statics with the same
name in one file anyways.
Well, I guess you somehow can (just like the doctests do), but it does make
sense to declare drivers in such a way.
I think as long as we take care that separate Rust modules can't interfere with
each other it's good enough.
>
> For example adding a second FooDriver example to platform.rs won't be
> possible?
Not unless you change the identifier name unfortunately. But that might be
fixable by putting doctests in separate `mod $(DOCTEST) {}` blocks.
>
> +/// struct FooDriver;
> +///
> +/// kernel::of_device_table!(
> +/// OF_TABLE,
> +/// MODULE_OF_TABLE,
> +/// <FooDriver as platform::Driver>::IdInfo,
> +/// [
> +/// (of::DeviceId::new(c_str!("test,rust-device2")), ())
> +/// ]
> +/// );
>
> Best regards
>
> Dirk
>
>
>
>
next prev parent reply other threads:[~2024-10-29 9:50 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-22 21:31 [PATCH v3 00/16] Device / Driver PCI / Platform Rust abstractions Danilo Krummrich
2024-10-22 21:31 ` [PATCH v3 01/16] rust: init: introduce `Opaque::try_ffi_init` Danilo Krummrich
2024-10-29 12:42 ` Alice Ryhl
2024-10-22 21:31 ` [PATCH v3 02/16] rust: introduce `InPlaceModule` Danilo Krummrich
2024-10-29 12:45 ` Alice Ryhl
2024-11-04 0:15 ` Greg KH
2024-11-04 17:36 ` Miguel Ojeda
2024-10-22 21:31 ` [PATCH v3 03/16] rust: pass module name to `Module::init` Danilo Krummrich
2024-10-29 12:55 ` Alice Ryhl
2024-10-22 21:31 ` [PATCH v3 04/16] rust: implement generic driver registration Danilo Krummrich
2024-10-22 21:31 ` [PATCH v3 05/16] rust: implement `IdArray`, `IdTable` and `RawDeviceId` Danilo Krummrich
2024-11-25 13:42 ` Miguel Ojeda
2024-10-22 21:31 ` [PATCH v3 06/16] rust: add rcu abstraction Danilo Krummrich
2024-10-29 13:59 ` Alice Ryhl
2024-10-22 21:31 ` [PATCH v3 07/16] rust: add `Revocable` type Danilo Krummrich
2024-10-29 13:26 ` Alice Ryhl
2024-12-03 9:21 ` Danilo Krummrich
2024-12-03 9:24 ` Alice Ryhl
2024-12-03 9:35 ` Danilo Krummrich
2024-12-03 10:58 ` Alice Ryhl
2024-10-22 21:31 ` [PATCH v3 08/16] rust: add `dev_*` print macros Danilo Krummrich
2024-11-04 0:24 ` Greg KH
2024-10-22 21:31 ` [PATCH v3 09/16] rust: add `io::Io` base type Danilo Krummrich
2024-10-28 15:43 ` Alice Ryhl
2024-10-29 9:20 ` Danilo Krummrich
2024-10-29 10:18 ` Alice Ryhl
2024-11-06 23:44 ` Daniel Almeida
2024-11-06 23:31 ` Daniel Almeida
2024-10-22 21:31 ` [PATCH v3 10/16] rust: add devres abstraction Danilo Krummrich
2024-10-31 14:03 ` Alice Ryhl
2024-11-27 12:21 ` Alice Ryhl
2024-11-27 13:19 ` Danilo Krummrich
2024-11-27 13:20 ` Alice Ryhl
2024-10-22 21:31 ` [PATCH v3 11/16] rust: pci: add basic PCI device / driver abstractions Danilo Krummrich
2024-10-27 22:42 ` Boqun Feng
2024-10-28 10:21 ` Danilo Krummrich
2024-11-26 14:06 ` Danilo Krummrich
2024-10-29 21:16 ` Christian Schrefl
2024-10-22 21:31 ` [PATCH v3 12/16] rust: pci: implement I/O mappable `pci::Bar` Danilo Krummrich
2024-10-22 21:31 ` [PATCH v3 13/16] samples: rust: add Rust PCI sample driver Danilo Krummrich
2024-10-23 15:57 ` Rob Herring
2024-10-28 13:22 ` Danilo Krummrich
2024-10-22 21:31 ` [PATCH v3 14/16] rust: of: add `of::DeviceId` abstraction Danilo Krummrich
2024-10-22 23:03 ` Rob Herring
2024-10-23 6:33 ` Danilo Krummrich
2024-10-27 4:38 ` Fabien Parent
2024-10-29 13:37 ` Alice Ryhl
2024-10-22 21:31 ` [PATCH v3 15/16] rust: platform: add basic platform device / driver abstractions Danilo Krummrich
2024-10-22 23:47 ` Rob Herring
2024-10-23 6:44 ` Danilo Krummrich
2024-10-23 14:23 ` Rob Herring
2024-10-28 10:15 ` Danilo Krummrich
2024-10-30 12:23 ` Rob Herring
2024-11-26 12:39 ` Danilo Krummrich
2024-11-26 14:44 ` Rob Herring
2024-11-26 15:17 ` Danilo Krummrich
2024-11-26 19:15 ` Rob Herring
2024-11-26 20:01 ` Danilo Krummrich
2024-10-24 9:11 ` Dirk Behme
2024-10-28 10:19 ` Danilo Krummrich
2024-10-29 7:20 ` Dirk Behme
2024-10-29 8:50 ` Danilo Krummrich
2024-10-29 9:19 ` Dirk Behme
2024-10-29 9:50 ` Danilo Krummrich [this message]
2024-10-29 9:55 ` Danilo Krummrich
2024-10-29 10:08 ` Dirk Behme
2024-10-30 13:18 ` Rob Herring
2024-10-27 4:32 ` Fabien Parent
2024-10-28 13:44 ` Dirk Behme
2024-10-29 13:16 ` Alice Ryhl
2024-10-30 15:50 ` Alice Ryhl
2024-10-30 18:07 ` Danilo Krummrich
2024-10-31 8:23 ` Alice Ryhl
2024-11-26 14:13 ` Danilo Krummrich
2024-12-04 19:25 ` Daniel Almeida
2024-12-04 19:30 ` Danilo Krummrich
2024-10-22 21:31 ` [PATCH v3 16/16] samples: rust: add Rust platform sample driver Danilo Krummrich
2024-10-23 0:04 ` Rob Herring
2024-10-23 6:59 ` Danilo Krummrich
2024-10-23 15:37 ` Rob Herring
2024-10-28 9:32 ` Danilo Krummrich
2024-10-25 10:32 ` Dirk Behme
2024-10-25 16:08 ` Rob Herring
2024-10-23 5:13 ` [PATCH v3 00/16] Device / Driver PCI / Platform Rust abstractions Greg KH
2024-10-23 7:28 ` Danilo Krummrich
2024-10-25 5:15 ` Dirk Behme
2024-11-16 14:32 ` Janne Grunau
2024-11-16 14:50 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZyCvyrb5jsY1O4uX@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@samsung.com \
--cc=airlied@gmail.com \
--cc=ajanulgu@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=devicetree@vger.kernel.org \
--cc=dirk.behme@de.bosch.com \
--cc=fujita.tomonori@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lina@asahilina.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=saravanak@google.com \
--cc=tmgross@umich.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).