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

[Miguel Ojeda]

On Mon, Mar 31, 2025 at 6:39 PM Yury Norov <yury.norov@xxxxxxxxx> 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