public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Armin Wolf <W_Armin@gmx.de>
To: Gladyshev Ilya <foxido@foxido.dev>
Cc: "Len Brown" <lenb@kernel.org>, "Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Tamir Duberstein" <tamird@gmail.com>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: Re: [RFC PATCH 2/3] rust: introduce WMI abstractions
Date: Sun, 28 Dec 2025 22:02:05 +0100	[thread overview]
Message-ID: <ebfacf87-ce3a-49a0-90b3-74574eca0cec@gmx.de> (raw)
In-Reply-To: <d8033c40-9cac-4827-9d8a-5cb3d727ec5b@foxido.dev>

Am 25.12.25 um 21:37 schrieb Gladyshev Ilya:

> On 12/25/25 21:06, Armin Wolf wrote:
>>> +// SAFETY: A call to `unregister` for a given instance of `RegType` 
>>> is guaranteed to be valid if
>>> +// a preceding call to `register` has been successful.
>>> +unsafe impl<T: Driver + 'static> driver::RegistrationOps for 
>>> Adapter<T> {
>>> +    type RegType = bindings::wmi_driver;
>>> +
>>> +    unsafe fn register(
>>> +        wdrv: &Opaque<Self::RegType>,
>>> +        name: &'static CStr,
>>> +        module: &'static ThisModule,
>>> +    ) -> Result {
>>> +        macro_rules! map_callback {
>>> +            ($flag:ident -> $callback:ident) => {
>>> +                if T::$flag {
>>> +                    Some(Self::$callback)
>>> +                } else {
>>> +                    None
>>> +                }
>>> +            };
>>> +        }
>>> +
>>> +        // SAFETY: It's safe to set the fields of `struct 
>>> wmi_driver` on initialization.
>>> +        unsafe {
>>> +            (*wdrv.get()).driver.name = name.as_char_ptr();
>>> +            (*wdrv.get()).driver.probe_type = 
>>> bindings::probe_type_PROBE_PREFER_ASYNCHRONOUS;
>>> +            (*wdrv.get()).id_table = T::TABLE.as_ptr();
>>> +            (*wdrv.get()).probe = map_callback!(HAS_PROBE -> 
>>> probe_callback);
>>> +            (*wdrv.get()).notify = map_callback!(HAS_NOTIFY -> 
>>> notify_callback);
>>
>> I think it should be possible to handle WMI drivers requiring 
>> .no_notify_data to be set. Is there
>> a way to declare the WMI event data passed to the notify() callback 
>> as optional? If yes, then i suggest
>> that we always set .no_notify_data and simply require the WMI drivers 
>> themselves to verify that a given
>> WMI event does contain additional event data.
>
> Yes, I can change the notify API to receive Optional<&AcpiBuffer> 
> instead of &AcpiBuffer, so every driver will be forced to verify 
> payload existence by Rust's type system.
>
> IIRC, casting raw (C) pointer to Optional<&T> is actually a no-op in 
> Rust, since NULL is automatically mapped to None (empty Optional), so 
> it will be a zero-cost typesystem win :)

Nice, then i suggest you always set .no_notify_data and pass the event data inside said Optional.

Thanks,
Armin Wolf


  reply	other threads:[~2025-12-28 21:02 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-21 18:22 [RFC PATCH 0/3] rust: WMI abstractions Gladyshev Ilya
2025-12-21 18:22 ` [RFC PATCH 1/3] rust: implement wrapper for acpi_object Gladyshev Ilya
2025-12-22 11:35   ` Danilo Krummrich
2025-12-22 21:47     ` Gladyshev Ilya
2025-12-22 22:44       ` Danilo Krummrich
2025-12-23 15:02         ` Gladyshev Ilya
2025-12-22 19:32   ` Rafael J. Wysocki
2025-12-23 16:36     ` Gladyshev Ilya
2025-12-21 18:22 ` [RFC PATCH 2/3] rust: introduce WMI abstractions Gladyshev Ilya
2025-12-22 11:50   ` Danilo Krummrich
2025-12-25 18:06   ` Armin Wolf
2025-12-25 20:37     ` Gladyshev Ilya
2025-12-28 21:02       ` Armin Wolf [this message]
2025-12-21 18:22 ` [RFC PATCH 3/3] rust: sample driver for WMI demonstrations Gladyshev Ilya
2025-12-22 11:52 ` [RFC PATCH 0/3] rust: WMI abstractions Danilo Krummrich
2025-12-22 21:30   ` Gladyshev Ilya
2025-12-25 17:56     ` Armin Wolf

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=ebfacf87-ce3a-49a0-90b3-74574eca0cec@gmx.de \
    --to=w_armin@gmx.de \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=foxido@foxido.dev \
    --cc=gary@garyguo.net \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@gmail.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