Skip to content
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

Split "shared" userspace & kernel code into separate files #16492

Closed
wants to merge 6 commits into from

Conversation

robn
Copy link
Member

@robn robn commented Aug 31, 2024

Motivation and Context

My continuing mission to make libzpool into a first-class citizen.

Why I've chosen that as a mission is a whole separate thing, that I'm planning on a talk on. For now, at least, lets say similar reasons as #16253: I would like to experiment with different implementations for some of these things in both the kernel and in userspace, and them sharing code makes it tough to change one without worrying about breaking the other.

Description

lib/libzpool/Makefile.am lists a few files that are shared between userspace and the Linux kernel. This commit gives userspace its own source for all but two of these:

  • arc_os.c: mostly no shared code, just lift the userspace code out
  • trace.c: remove from userspace builds, its already an effective no-op
  • vdev_label_os.c: already a no-op for Linux, just copy it
  • zfs_debug.c: just a very straightforward list-based implementation for userspace, and the printing functions only exist there
  • zfs_racct.c: already a no-op for Linux, just copy it
  • zfs_znode.c: much of the Linux and FreeBSD code was identical, so lifted all that into a common zfs_znode.c. Userspace has no ZPL (yet), so no need for an implementation of this for it.

The remaining files (vdev_file.c, zio_crypt.c) require more work, so I'll get them in a future PR.

How Has This Been Tested?

Build checked on Linux 6.1.99 and FreeBSD 14.1. ZTS run within error bars 💀

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:

Copy link
Member

@amotin amotin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks fine on a quick look. Just one minor thought:

Comment on lines 32 to 36
/*
* Check if the reserved boot area is in-use.
*
* This function always returns 0, as there are no known external uses
* of the reserved area on Linux.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FreeBSD might use reserved area for booting in case of MBR partitioning. If it is relevant here and now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just lifted the existing code. I don't know what happens on FreeBSD really. If you can give me a brief description I can put a TODO comment in here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not something that is really happenING, more like happenED. Before GPT spread there was a weird way of booting from ZFS on MBR, which IIRC included storing some boot code in the reserved areas of ZFS, which is incompatible with RAIDZ expansion. I've never done ZFS on MBR myself, and these days I am not sure many people use MBR at all, so it may be a moot point. Also I am not sure whether this function is really useful for user-space code, so was merely bringing an attention to think of possible functionality loss.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've updated the comment. I think probably the kernel FreeBSD version could actually just be the generic version for all platforms, because I don't really see why an apparently-in-use reserved area should be ignored in Linux; what if its a dual-boot system or something? But I think that's for a future change.

@lundman
Copy link
Contributor

lundman commented Sep 7, 2024

So I understand, we will then have a separate zfs_znode.c for just useland, and manually keep the sources synchronised? Is that better?

@robn
Copy link
Member Author

robn commented Sep 7, 2024

So I understand, we will then have a separate zfs_znode.c for just useland, and manually keep the sources synchronised? Is that better?

There is a common zfs_znode.c for all variants, then an OS-specific zfs_znode_os.c that provides the glue to the platform filesystem layer (eg kernel VFS). Userspace has never had such glue; it was all behind #ifdef _KERNEL before, so nothing is lost. If it ever does have such glue (not sure what that looks like), then it'd be in lib/libzpool/zfs_znode.os.c or something.

The intent here is to not have to keep things in sync; before this PR, module/os/linux/zfs/zfs_znode.c and module/os/freebsd/zfs/zfs_znode.c had a lot of duplicate code; now its shared.

@lundman
Copy link
Contributor

lundman commented Sep 7, 2024

Nice, then I follow, carry on

@behlendorf behlendorf added the Status: Accepted Ready to integrate (reviewed, tested) label Sep 13, 2024
The Linux arc_os.c carries userspace and kernel code, with very little
overlap between the two. This lifts the userspace parts out into a
separate arc_os.c for libzpool and removes it from the Linux side.

Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
The no-op is fine for both.

Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
It does nothing in userspace anyway.

Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
The no-op is fine for both.

Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
For now, userspace has no znode implementation. Some of the property and
path handling code is used there though and is the same on all
platforms, so we only need a single copy of it.

Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Just nice and simple, with room to grow.

Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
behlendorf pushed a commit that referenced this pull request Sep 19, 2024
The no-op is fine for both.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes #16492
behlendorf pushed a commit that referenced this pull request Sep 19, 2024
It does nothing in userspace anyway.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes #16492
behlendorf pushed a commit that referenced this pull request Sep 19, 2024
The no-op is fine for both.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes #16492
behlendorf pushed a commit that referenced this pull request Sep 19, 2024
For now, userspace has no znode implementation. Some of the property and
path handling code is used there though and is the same on all
platforms, so we only need a single copy of it.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes #16492
behlendorf pushed a commit that referenced this pull request Sep 19, 2024
Just nice and simple, with room to grow.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes #16492
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Sep 20, 2024
The Linux arc_os.c carries userspace and kernel code, with very little
overlap between the two. This lifts the userspace parts out into a
separate arc_os.c for libzpool and removes it from the Linux side.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes openzfs#16492
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Sep 20, 2024
The no-op is fine for both.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes openzfs#16492
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Sep 20, 2024
It does nothing in userspace anyway.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes openzfs#16492
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Sep 20, 2024
The no-op is fine for both.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes openzfs#16492
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Sep 20, 2024
For now, userspace has no znode implementation. Some of the property and
path handling code is used there though and is the same on all
platforms, so we only need a single copy of it.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes openzfs#16492
mcmilk pushed a commit to mcmilk/zfs that referenced this pull request Sep 20, 2024
Just nice and simple, with room to grow.

Reviewed by: Brian Behlendorf <[email protected]>
Reviewed-by: Alexander Motin <[email protected]>
Signed-off-by: Rob Norris <[email protected]>
Sponsored-by: https://despairlabs.com/sponsor/
Closes openzfs#16492
amotin added a commit to amotin/zfs that referenced this pull request Oct 18, 2024
For some reason it was dropped when split from kernel, that makes
raidz_test to accumulate in RAM up to 100GB of logs we don't need.

Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Fixes openzfs#16492
Fixes openzfs#16566
behlendorf pushed a commit that referenced this pull request Oct 20, 2024
For some reason it was dropped when split from kernel, that makes
raidz_test to accumulate in RAM up to 100GB of logs we don't need.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Igor Kozhukhov <[email protected]>
Reviewed-by:  Rob Norris <[email protected]>
Reviewed-by: Tino Reichardt <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes #16492
Closes #16566
Closes #16664
behlendorf pushed a commit to behlendorf/zfs that referenced this pull request Oct 21, 2024
For some reason it was dropped when split from kernel, that makes
raidz_test to accumulate in RAM up to 100GB of logs we don't need.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Igor Kozhukhov <[email protected]>
Reviewed-by:  Rob Norris <[email protected]>
Reviewed-by: Tino Reichardt <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16492
Closes openzfs#16566
Closes openzfs#16664
behlendorf pushed a commit to behlendorf/zfs that referenced this pull request Oct 21, 2024
For some reason it was dropped when split from kernel, that makes
raidz_test to accumulate in RAM up to 100GB of logs we don't need.

Reviewed-by: Brian Behlendorf <[email protected]>
Reviewed-by: Igor Kozhukhov <[email protected]>
Reviewed-by:  Rob Norris <[email protected]>
Reviewed-by: Tino Reichardt <[email protected]>
Signed-off-by:	Alexander Motin <[email protected]>
Sponsored by:	iXsystems, Inc.
Closes openzfs#16492
Closes openzfs#16566
Closes openzfs#16664
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Accepted Ready to integrate (reviewed, tested)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants