On Tue, Jul 07, 2026 at 04:13:30PM +0200, Greg KH wrote: > On Tue, Jul 07, 2026 at 10:25:27PM +0900, Eliot Courtney wrote: > > On Fri Jul 3, 2026 at 7:31 PM JST, Greg KH wrote: > > > On Fri, Jul 03, 2026 at 07:16:06PM +0900, Eliot Courtney wrote: > > >> Add support for contiguous area allocation. Add a new type, > > >> `UnusedArea`, following the same pattern as `UnusedId`. > > >> > > >> Signed-off-by: Eliot Courtney <[email protected]> > > > > > > Why isn't the built-in idr library being used here instead of rolling > > > your own data structure? > > > > > > thanks, > > > > > > greg k-h > > > > For nova-core in this series, we need allocation of a contiguous > > sequence of IDs with a specific length and sometimes a specific > > alignment. IIUC, IDA/xarray do not support that (I checked > > ida_alloc_range and it only allocates a single ID in a range, not a > > contiguous sequence). > > > > For IdPool before this series, I think it could have used IDA/xarray. > > See [1] where Alice has posted some more context. > > > > w.r.t. the structure choice, the IDs we need to allocate are channel > > IDs, and the total range is limited to 2048 of them, so IMO bitmaps are > > a better fit than e.g. maple tree. > > But again, you are having to "roll your own" logic here, please reuse > the data structures we already have in the kernel for this type of > thing. If a maple tree works, please use it.
I asked exactly the same question when Alice and Burak added wrappers for bitmaps to implement their ID pool. This is the answer: An alternative route of vendoring an existing Rust bitmap package was considered but suboptimal overall. Reusing the C implementation is preferable for a basic data structure like bitmaps. It enables Rust code to be a lot more similar and predictable with respect to C code that uses the same data structures and enables the use of code that has been tried-and-tested in the kernel, with the same performance characteristics whenever possible. And now it's in a commit message: 11eca92a2caeb They measured the affect of their wrapper on performance, and it appears to be ~5%. See lib/find_bit_benchmark_rust.rs. I didn't see any side-to-side comparison between any native Rust API vs imported C bitmaps. I'm sure, I asked for that, and I still believe it's the important piece of data to avoid this back-and-forth type of discussions. So, Alice, Burak or anybody... > > > Why isn't the built-in idr library being used here instead of rolling > > > your own data structure? Now having more context, the ID pool's primary goal is to allocate individual IDs, which naturally lays on find_bit() API in C. The native Rust alternative is considered and found 'suboptimal overall'. This series extends the existing data structure in Rust for Linux, not adding a new one. So, the series itself looks justified to me because it's a logical extension of the existing functionality. Regarding C bindings vs native API... Yes we lack thorough performance analysis. Do we have such analysis for every data structure in kernel? No. So to me it's as simple as: they are developers, they know better. Thanks, Yury
