linux-kernel - Re: [PATCH v4 13/13] samples: rust: add Rust platform sample driver

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: <626b3707-c2cb-4239-b6f8-8b33e45e7874@gmail.com>
Date: Fri, 6 Dec 2024 07:39:02 +0100
From: Dirk Behme <dirk.behme@...il.com>
To: Rob Herring <robh@...nel.org>
Cc: Danilo Krummrich <dakr@...nel.org>, gregkh@...uxfoundation.org,
 rafael@...nel.org, bhelgaas@...gle.com, ojeda@...nel.org,
 alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
 bjorn3_gh@...tonmail.com, benno.lossin@...ton.me, tmgross@...ch.edu,
 a.hindborg@...sung.com, aliceryhl@...gle.com, airlied@...il.com,
 fujita.tomonori@...il.com, lina@...hilina.net, pstanner@...hat.com,
 ajanulgu@...hat.com, lyude@...hat.com, daniel.almeida@...labora.com,
 saravanak@...gle.com, dirk.behme@...bosch.com, j@...nau.net,
 fabien.parent@...aro.org, chrisi.schrefl@...il.com,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-pci@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v4 13/13] samples: rust: add Rust platform sample driver

Hi Rob,

On 05.12.24 19:03, Rob Herring wrote:
> On Thu, Dec 5, 2024 at 11:09 AM Dirk Behme <dirk.behme@...il.com> wrote:
>>
>> Hi Danilo,
>>
>> On 05.12.24 15:14, Danilo Krummrich wrote:
>>> Add a sample Rust platform driver illustrating the usage of the platform
>>> bus abstractions.
>>>
>>> This driver probes through either a match of device / driver name or a
>>> match within the OF ID table.
>>>
>>> Signed-off-by: Danilo Krummrich <dakr@...nel.org>
>>
>> Not a review comment, but a question/proposal:
>>
>> What do you think to convert the platform sample into an example/test?
>> And drop it in samples/rust then? Like [1] below?
>>
>> We would have (a) a complete example in the documentation and (b) some
>> (KUnit) test coverage and (c) have one patch less in the series and
>> (d) one file less to maintain long term.
> 
> I think that's going to become unwieldy when/if we add properties,
> iomem, and every other thing a driver can call in probe.


Yes, I agree. In your property RFC you added some (nice!) property
access examples to the sample we are talking about here. That would
become difficult with the documentation/Kunit example proposed here.
So I think there are pros & cons for both options ;)


> OTOH, the need for the sample will quickly diminish once there are
> real drivers using this stuff.
> 
>> I think to remember that it was mentioned somewhere that a
>> documentation example / KUnit test is preferred over samples/rust (?).
> 
> Really? I've only figured out how you build and run the samples. I
> started looking into how to do the documentation kunit stuff and still
> haven't figured it out. 

If you like try CONFIG_KUNIT=y and CONFIG_RUST_KERNEL_DOCTESTS=y.

I guess it will run automatically at boot, then. For me that was the
easiest way. But yes, everything else will need some additional steps.

Dirk

> I'm sure it is "easy", but it's not as easy as
> the samples and yet another thing to go learn with the rust stuff. For
> example, just ensuring it builds is more than just "compile the
> kernel". We already have so many steps for submitting things upstream
> and rust is just adding more on top.