linux-kernel - Re: [PATCH v6 0/4] rust: adds Bitmap API, ID pool and bindings

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: <CANiq72kSVHsgZGULhy+t4XyD2xGAKdiyKshC1VgKjTFoHUbMNg@mail.gmail.com>
Date: Mon, 31 Mar 2025 20:52:26 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Burak Emir <bqe@...gle.com>, Rasmus Villemoes <linux@...musvillemoes.dk>, 
	Viresh Kumar <viresh.kumar@...aro.org>, 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>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 0/4] rust: adds Bitmap API, ID pool and bindings

On Mon, Mar 31, 2025 at 6:39 PM Yury Norov <yury.norov@...il.com> wrote:
>
> I didn't find any discussions related to the bit_set in kernel context.
> Is it possible to use it in kernel? If not, can you mention that in commit

In principle, from a very quick look, yes, it supports `no_std` and
should be very easy to vendor since they don't have dependencies (i.e.
`bit_set` and `bit_vec`).

> message? If yes, I think you should consider to use internal language
> tools.

Hmm... if by "internal language tools" you mean a normal library (like
that one you mention), then yeah, they can be considered.

In general, we have been prudent about using third-party libraries so
far, but it is possible if it is the right choice -- please see:

    https://rust-for-linux.com/third-party-crates#suitability-of-a-crate

So if everyone agrees that or another library would be the best fit
than mimicking or using the C side (performance-wise,
maintainability-wise, etc.), then I am happy to integrate it.

> I encourage you to implement the tests as normal kernel tests - in
> source files that may be enabled in config. I can't insist on that,
> and will not block the series because of lack of benchmarks and
> tests written in a traditional way.
>
> But to me, scattered wrongly formatted commented-out in-place way of
> writing tests is something fundamentally wrong. Not mentioning that
> it bloats source files, making them harder to read.

I don't think documentation makes things harder to read; quite the
opposite -- if the docs are good.

But, yeah, if it is an actual test that is not suitable as an example,
then it should be a separate test (whether as a `#[test]` one, if that
works already for this use case, or as a sample module otherwise).

Thanks!

Cheers,
Miguel