Skip to content

tunables: general code cleanup #17377

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

Conversation

robn
Copy link
Member

@robn robn commented May 24, 2025

Motivation and Context

Our tunables/module parameters infrastructure has accumulated a lot of cruft over time, making it pretty difficult to work with. I've been working quietly over the last year on a general uplift. The first thing to do though is make a run at the obvious things, which is this PR: a goodie bag of miscellaneous tunable-related cleanups.

This PR is just the internal code cleanup. See #17375 and #17376 for the user-visible changes (removing old tunables proper).

Description

See the individual commits. Commit summaries:

  • zfs_log: make zfs_immediate_write_sz uint
  • tunables: don't assert initialisation in impl getters
  • tunables: ensure tunable and variable have same define gate
  • tunables: remove FreeBSD compat macros for Linux module params
  • tunables: remove direct use of module_param_cb
  • tunables: remove support for s64 tunables
  • tunables: use Linux ullong param ops for u64
  • tunables: remove unused param get/set aliases
  • tunables: remove __check_old_set_param workaround
  • tunables: fix spelling

Includes e2345d1 from #17376 to keep it compiling on FreeBSD after the no-op compat macros module_param_named and MODULE_PARAM_DESC removed. However, that commit is part of that PR, not this, and if its merged earlier, I will rebase this one on top of it.

How Has This Been Tested?

Compile checked on Linux and FreeBSD.

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)
  • Quality assurance (non-breaking change which makes the code more robust against bugs)
  • 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:

@amotin
Copy link
Member

amotin commented May 25, 2025

@robn Does not build on FreeBSD.

@amotin amotin added the Status: Revision Needed Changes are required for the PR to be accepted label May 25, 2025
@robn
Copy link
Member Author

robn commented May 25, 2025

But! It! I!... gragh!

robn added 11 commits May 25, 2025 12:20
It's been many years, we can probably do without.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
Likely it's only int64 for comparison with ssize_t, which is signed.
However, it would make no sense for it to be less than 0 or greater than
4G, so making it a regular uint will make it safe for comparison and
remove the only S64 tunable in core.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
It actually doesn't matter if it's not initialised when we first query
the current value; it just returns empty-string. A crash is quite
obnoxious even if it is a rare case.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
If a variable is only available in the kernel, then the tunable should
also only be available there.

This matters very little so long as we don't have userspace tunables,
but its still good hygeine.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
Nothing in any FreeBSD code uses them.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
The use for spl_taskq_kick was the only use, and the comment that
module_param_call is obsolete is no longer true - it's still very much
used even in recent kernels.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
Nothing uses them now.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
Since 3.17 Linux has provided param ops for 64-bit ints, so we don't
need to use our own anymore.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
This was fully removed from Linux in 4.15, so we won't be seeing it
again.

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
Three occurences with an 'e', and all of them mine. Maybe it's an
British thing?

Sponsored-by: https://despairlabs.com/sponsor/
Signed-off-by: Rob Norris <[email protected]>
@robn robn force-pushed the tunables-cleanup branch from 2d1de36 to 9a12d57 Compare May 25, 2025 02:21
@github-actions github-actions bot removed the Status: Revision Needed Changes are required for the PR to be accepted label May 25, 2025
@robn
Copy link
Member Author

robn commented May 25, 2025

@amotin fixed by pulling in a commit from #17376 temporarily. This all used to be one branch, then I decided I should split cleanup from user-visible changes for review, and I clearly didn't test properly after that. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants