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/[email protected]/ > > 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.
