Linux 6.12 compat: Rename range_tree_* to zfs_range_tree_*

[IvanVolosyuk]

Linux 6.12 has conflicting range_tree_{find,destroy,clear} symbols.

Motivation and Context

Linux 6.12 introduced conflicting symbols which cause issues when compiling zfs with --enable-linux-builtin
See #16932 for context.
The change fix compilation in this configuration.

Description

The change is basically:
find . -type f -exec sed -i 's/range_tree_/zfs_range_tree_/g' {} +
... and manually fixing lines > 80 characters to get checkstyle pass.

How Has This Been Tested?

No functional changes, linux kernel 6.12 with ZFS builtin compiled successfully.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[amotin]

This is incredibly invasive change. Wish there was some easier one, but whatever. Just a couple thoughts:

• I would not rename metaslab_calculate_range_tree_type();
• You are renaming some things in range_tree.h, but not others. Sure I don't want even more changes, just the logic looks inconsistent.

[IvanVolosyuk]

Yeah, the change was pretty mechanical, I literally ran:
find . -type f -exec sed -i 's/range_tree_/zfs_range_tree_/g' {} +

What did I miss in range_tree.h? I can definitely revert change to metaslab_calculate_range_tree_type.
What about range_tree_t, I can keep it as it is - types cannot conflict with kernel symbols and it will remove a lot of churn.

[behlendorf]

What about range_tree_t, I can keep it as it is - types cannot conflict with kernel symbols and it will remove a lot of churn.

It's unfortunate it's so invasive, but if we're going to have to make this change let's be consistent about it and use zfs_range_tree_t. We had to do the same thing for zfs_btree_t.

[IvanVolosyuk]

I reverted renaming of metaslab_calculate_range_tree_type(), which was changed by mistake.
If I understand @amotin correctly for consistency we want to rename rs_*, range_seg*, RANGE_SEG*. I did that in a separate commit for now. Let me know if I should squash it into the main one.

[IvanVolosyuk]

Alternative to this change would be adding following lines to range_tree.h:

#define range_tree_find zfs_range_tree_find
#define range_tree_find_in zfs_range_tree_find_in
#define range_tree_create zfs_range_tree_create
#define range_tree_destroy zfs_range_tree_destroy
#define range_tree_clear zfs_range_tree_clear

May be also add #ifdef guard, so that the renaming only happening in cases when zfs is compiled in into the kernel. It is kinda hacky way and will make stack traces strange for the bug reports coming from people with zfs compiled into the kernel.

[tonyhutter]

It is kinda hacky way and will make stack traces strange for the bug reports coming from people with zfs compiled into the kernel.

It's an interesting idea, but it does bring up the issues you mentioned. My vote is just to do the big rename.

[IvanVolosyuk]

I should probably rebase and squash the commits. Let me know when I should do that.

[tonyhutter]

@IvanVolosyuk yes, please squash these commits.

Could we get another reviewer to take a look at this? It looks nearly ready to go.

[robn]

Thanks for this; the mix of prefixed vs unprefixed things across the codebase make my eye do a twitchy thing :)

I'd prefer the remaining things in range_tree.h be converted, but also I know it sucks when these things drag on. So here's an approval, and a commit that I think does the remaining things: robn@7a3edae. Take it if you like, if not, I'll turn it into a PR to follow this one.

Good stuff!

[IvanVolosyuk]

@tonyhutter I squashed and pulled in @robn additional changes on top.

[tonyhutter]

@IvanVolosyuk thanks, looks good.

[IvanVolosyuk]

"Waiting on 1 reapproval from someone other than the last pusher. Review from tonyhutter is stale because it was submitted before the most recent code changes."

Looks like I need another approval or re-approval. @behlendorf may be? I don't know if @robn approval counts if I include his changes as well :)

[tonyhutter]

@robn any additional comments on this? If you're happy with it then I'll pull it in.

[robn]

@tonyhutter still good! ✔️

[tonyhutter]

Merged as d4a5a7e 68473c4