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] [day] [month] [year] [list]

Message-ID: <CACQBu=V+OrsgBTv3hhWgFhGCBOXC=ytDwcS5v=j8uKcrDaXb6Q@mail.gmail.com>
Date: Wed, 23 Apr 2025 14:00:52 +0200
From: Burak Emir <bqe@...gle.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Yury Norov <yury.norov@...il.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 8:52 PM Miguel Ojeda
<miguel.ojeda.sandonis@...il.com> wrote:
>
> 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.
>

IMHO, we should strive to avoid parallel implementations of basic data
structures.

This little patch series was started to replace a self-contained C
code with Rust implementation. It may not representative for all Rust
code, but building an abstraction over C code will make porting a lot
easier to write and review.

Now, one can argue that Rust abstractions could use alternative
implementations instead of binding the C code underneath. This opens
the door to subtle differences in performance or correctness (e.g. the
case with atomics and inner mutability).

> > 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).
>

Now that I figured out how to do it, I'll add the separate kunit test
that exercise code paths which are not helpful in documentation.

Thanks,
Burak