linux-kernel - Re: [PATCH 10/10] samples: rust: platform: Add property read examples

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: <CAL_JsqK0SH+HTtquxDNvp8jCLwJgg7YJDNQT8h=kHO=nJChk4Q@mail.gmail.com>
Date: Wed, 26 Mar 2025 19:02:56 -0500
From: Rob Herring <robh@...nel.org>
To: Remo Senekowitsch <remo@...nzli.dev>
Cc: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Daniel Scally <djrscally@...il.com>, 
	Heikki Krogerus <heikki.krogerus@...ux.intel.com>, 
	Sakari Ailus <sakari.ailus@...ux.intel.com>, Dirk Behme <dirk.behme@...bosch.com>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>, 
	Danilo Krummrich <dakr@...nel.org>, Saravana Kannan <saravanak@...gle.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, 
	Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, linux-kernel@...r.kernel.org, 
	linux-acpi@...r.kernel.org, devicetree@...r.kernel.org, 
	rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 10/10] samples: rust: platform: Add property read examples

On Wed, Mar 26, 2025 at 5:24 PM Remo Senekowitsch <remo@...nzli.dev> wrote:
>
> On Wed Mar 26, 2025 at 11:01 PM CET, Rob Herring wrote:
> >>
> >> +        let prop = dev
> >> +            .property_read::<bool>(c_str!("test,bool-prop"))
> >> +            .required()?;
> >
> > The 'required' is kind of odd for boolean properties. They are never
> > required as not present is the only way to to get false.
>
> Agreed. I can think of a few alternatives:
>
> * Make the trait `Property` more flexible to allow each implementor to specify
>   what its output type for the `read` function is, via an associated type.
>   I really don't like this idea, because overly generic APIs can mess with type
>   inference and become less ergonomic because of it.
>
> * Use `propert_present` instead. That doesn't perfectly express the intention,
>   because it doesn't warn if the property is present but has a type other than
>   bool.

Right. I've been cleaning up the tree to use of_property_read_bool()
on bools and of_property_present() on non-bools, so don't want to go
back to 1 function. The C code now warns on a mismatch.

> * Add an additional inherent method `property_read_bool`, which returns a plain
>   `bool` instead of `PropertyGuard<bool>`. Then there will be three slightly
>   different ways to read a bool: `property_present`, `property_read_bool` and
>   `property_read::<bool>`. Maybe that's confusing.
>
> * Add `property_read_bool` and remove `impl Property for bool`. That would avoid
>   confusion between `property_read_bool` and `property_read::<bool>`, only the
>   former would work.

I think I would go with this option. Easier to add another way later
than remove one.

Rob