Lift userspace definitions out of zfs_context.h

[robn]

Motivation and Context

As part of my ongoing project to make userspace into a "first class" platform, and to make OpenZFS easier to port to other platforms, I am working to make headers consistent across all platforms. I would like to get to a point where zfs_context.h is the same for all platforms and compile modes, and so provides a complete list of "necessary to implement" for any platform.

The first part of that is to lift all the userspace-specific stuff out of zfs_context.h into separated headers in lib/libspl/include. That's this PR.

This PR deliberately stops at emptying zfs_context.h of definitions. The next PR I open on this project will collapse it into a single list of headers that works across all platforms, but that will require movement across all platform headers, not just userspace, and I don't want to complicate review on this further.

Description

There's a lot of commits here, but they are basically just picking a specific concept or object from the userspace part zfs_context.h and moving it out to a specific header under lib/libspl/include. For most, that header does not already exist. For some, it does exist but wasn't used, or was in conflict, and has been updated appropriately.

After that, there's a long tail of misc stuff, which has been either moved somewhere more appropriate or deleted.

I expect that much of this could be collapsed into a smaller set of commits, but for the moment I'm keeping them separate for review.

How Has This Been Tested?

This should all be entirely mechanical, so anything that compiles should work.

The final series compiles on Linux and FreeBSD, and ZTS passes.

It should compile clean at each individual commit, but I have moved things around a little while assembling the final series, so something may be stacked wrong. I'll go and check that now, but its also pretty low-key.

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:

• 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.

[behlendorf]

Very nice! Aside from a a couple small nits this is a welcome bit of long overdue refactoring.

For next steps I think it would make the most sense to move the remaining user space implementations out of libzpool and into libspl. It looks like lib/libzpool/kernel.c and lib/libzpool/taskq.c should cover almost everything.

Do you want to tackle that in this PR or another? I'm fine with pulling in this whole stack of commits, having it broken up made it much easier to review.

[behlendorf]

handle_tunable_option should probably get moved to lib/libspl/include/sys/tunables.h.

[behlendorf]

Since this take a struct spa * I think we really should somehow keep this with libzpool and out of libspl. We could definitely take care of that little cleanup in one of the planned following changes.

[robn]

Actually, responding to both your comments, I realised what happened here: zfs_context_os.h should not be in libspl - its for the "zfs module", not the SPL! That's why it doesn't make sense!

Both those functions are very libzpool-specific, so they can either say in zfs_context_os.h when I move it away from libspl, or they can go to a libzpool.h, along with kernel_init() etc - things the program needs to drive libzpool, not things that the module internals need to operate.

I'll give it a try. I think there's at least enough overlap with this PR that it could go here, but I'll see how it shakes out - if its ick enough, maybe the next PR is better. More soon!