Make the vfs.zfs.vdev.raidz_impl sysctl cross-platform

[asomers]

Signed-off-by: Alan Somers [email protected]
Sponsored by: ConnectWise

Motivation and Context

It creates a vfs.zfs.vdev.raidz_impl sysctl on FreeBSD, so the implementation can be queried or changed.

Description

Replace the Linux-specific module_param_call and MODULE_PARM_DESC with the portable ZFS_MODULE_PARAM_CALL.

How Has This Been Tested?

Tested on FreeBSD. Tried creating pools with every available raidz_impl testing. On Linux, compile-tested only.

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. (the setting was already in the man page)
• 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]

It seems you are stil changing the behavior on Linus by using param_get_charp() instead of vdev_raidz_impl_get() before. I am not sure it is possible to drop the zfs_vdev_raidz_impl variable completely with existing macros, but I don't think it is really needed here.

[asomers]

It seems you are stil changing the behavior on Linus by using param_get_charp() instead of vdev_raidz_impl_get() before. I am not sure it is possible to drop the zfs_vdev_raidz_impl variable completely with existing macros, but I don't think it is really needed here.

Yes, exactly. The existing macros seem to require that variable.

[amotin]

Yes, exactly. The existing macros seem to require that variable.

But nobody should force you to use it, if as I understand in this case arbitrary string needs to be produced.

[amotin]

That was an unexpected move.

[asomers]

That was an unexpected move.

Umm, what was unexpected?

[amotin]

That was an unexpected move.

Umm, what was unexpected?

Splitting the tunable into two completely separate for FreeBSD and Linux. You just missed one function, but decided to turn 180 degrees and go other direction.

[asomers]

Splitting the tunable into two completely separate for FreeBSD and Linux. You just missed one function, but decided to turn 180 degrees and go other direction.

Well, what would you like for me to do?

[amotin]

I was thinking you replace spl_param_get_charp() with a wrapper around vdev_raidz_impl_get().

[allanjude]

Reviewed-by: Allan Jude <[email protected]>

[amotin]

I have no objections, but asking myself how hard should we push cross-platform implementation for procedural parameters. It would be good, but use existing set of macros for it seemed pretty messy when Alan tried.

[asomers]

The latest push returns to using the cross-platform macro. I'm ok with committing either version.

[amotin]

I don't think you need to rename zfs_vdev_raidz_impl into zfs_vdev_raidz_impl_setting and add separate zfs_vdev_raidz_impl. Just leave them as they were. As I understand Linux will pass the argument to the get/set methods, which you may use or not. I wonder if it could be passed on FreeBSD also, so that we could avoid global symbol.

[amotin]

@asomers Take a note of checkstype error: ./module/os/linux/zfs/vdev_raidz.c: 32: unparenthesized return expression.