On Fri, Sep 18, 2026, Gokul K wrote: > sparsebit_copy() and sparsebit_num_set() have no callers. Nor does the > FUZZ harness at the bottom of lib/sparsebit.c, which exercises most of > the rest of the API and still builds and links with both removed. > > sparsebit_copy() was the only non-recursive caller of > node_copy_subtree(), which leaves that unreachable too. It is static, > so keeping it would trip -Wunused-function; delete it as well. > > The comment on the num_set member gives sparsebit_num_set() as the > reason the count is maintained. The member stays - it is what lets > sparsebit_all_set() answer in O(1), and the dump path prints it - so > point the comment at what still uses it. > > No functional change intended. > > Signed-off-by: Gokul K <[email protected]> > --- > .../testing/selftests/kvm/include/sparsebit.h | 2 - > tools/testing/selftests/kvm/lib/sparsebit.c | 63 +------------------ > 2 files changed, 1 insertion(+), 64 deletions(-) > > diff --git a/tools/testing/selftests/kvm/include/sparsebit.h > b/tools/testing/selftests/kvm/include/sparsebit.h > index e027e5790946..8a2ab11dae6f 100644 > --- a/tools/testing/selftests/kvm/include/sparsebit.h > +++ b/tools/testing/selftests/kvm/include/sparsebit.h > @@ -30,7 +30,6 @@ typedef u64 sparsebit_num_t; > > struct sparsebit *sparsebit_alloc(void); > void sparsebit_free(struct sparsebit **sbitp); > -void sparsebit_copy(struct sparsebit *dstp, const struct sparsebit *src);
I'm somewhat tempted to keep sparsebit_copy() even though there are no users. In the unlikely scenario someone wanted/needed to make a copy, it seems like a potentially painful waste of time to have to recreate this or hunt down its prior existence. Anyone else have an opinion?
