Re: [PATCH v9 8/9] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN

["Alexandre Courbot" <acourbot@nvidia.com>]

Hi Burak!

On Wed Oct 14, 2026 at 4:20 PM JST, Burak Emir wrote:
<...>
>> >
>> > Do the other patches in this series need this, or can we just drop this patch?
>> > If they do, maybe a demonstration of how significant the special-case
>> > handling is that can be avoided with the exact small capacity could be
>> > part of the commit message?
>>
>> The next patch in this series needs this to implement `ChannelIdPool`.
>> The alternative would be to track the actual length of the pool and
>> return an error if `IdPool` returns an ID after that value, which is
>> what v5 [1] was doing (see `num_chids` in the v5 code).
>>
>> That's the special-case handling that this patch is designed to avoid,
>> and I hope we can agree that it isn't a satisfying workaround,
>> especially when the backing `BitmapVec` *does* support exact sizes and
>> that artificial limitation is introduced by `IdPool` itself.
>>
>> [1] https://lore.kernel.org/all/20260812-chid-v5-5-6c767770b3f4@nvidia.com/
>
> Thanks for the link.
> To me, having IdPool support exact size seems nice-to-have.
>
> We are changing the design in light of different requirements, it is a
> defensible but not critical generalization.
> I was worried that we may need to have proper separate length and
> capacity fields (which contradicts the binder use case), but that is
> not the case.
>
> I checked the grow_request and grow dance now, it seems that even with
> exact small sizes we avoid allocating a bitmap.
> So I am not opposed. Like Yury, I find the 0 case slightly odd, but
> unlike Yury, I find that tolerable.
>
> The phrasing as "dropping an artificial limitation" does not
> adequately reflect that IdPool was done for a specific use case where
> the design made sense and is not actually a limitation.
>
> I wanted to highlight this perspective, because notwithstanding the
> name, IdPool was not meant to join the set of kernel's dedicated
> supported ID allocation mechanisms.

Given its name and location, I guess it was inevitable. :) But thanks
for clarifying its history, that helps understand the current design.

This also means we have two different use styles for this now:

- The binder style, where the pool grows as needed and we don't care
  about its exact size,
- The Nova (and likely others in the future) style, where we manage a
  set of finite resources that is not supposed to grow.

Which is what this patch tried to prepare for. Does it look acceptable
to you? I think we still want to merge it or something close to it.