> > > How about this: have your new RADIX_TREE_DUMP_CALLBACK option use the rtp->value
> > > (void *) member to store the callback function? As long as it's documented, I would
> > > have no problem accepting that as well.
> >
> > I think this is a good idea.
> >
> > Below is my plan,
> >
> > a. add the RADIX_TREE_DUMP_CB flag for do_radix_tree api.
> > b. Change the rtp definition, use union to replace original void * value definition.
> >
> > I think pre-build extension should be able to work with new code changes.
> > The union definition could make api easy to be understand.
>
> It may work with pre-existing extension modules, but if an extension module that uses
> a radix_tree_pair structure gets re-compiled, it fails like this:
>
> error: 'struct radix_tree_pair' has no member named 'value'
>
> I should have recommended using the radix_tree_pair.value as my first suggestion,
> but I was mistakenly thinking that your code was already using it. (although even
> if if you were using it, the value pointer could still be used, for example, to point
> to a data structure containing a array pointer and your callback function)
>
> So please just cast the value member to the callback function.
>
OK. I thought you just care about binary compatibility for pre-build modules.
For the module build based on source code, I think it is quite easy to switch to new version.
Anyway, I understand your strategy now. I will follow this way.