• rebase
• remove __KERNEL

In D26196#582060, @mahrens wrote:

Could we make this change upstream (in OpenZFS) rather than having to maintain the diff in freebsd? Or, would someone mind explaining when we would change the contrib files in FreeBSD vs changing them upstream?

Thanks

I will apply your patch, but it's a bit silly to call that "breaking world". -There's no guarantee that -DNO_CLEAN or -DNO_KERNELCLEAN will work across major changes.

@neel_neelc.org can you tell me a bit more about your environment, make universe builds for all of us and only the powerpcspe tinderbox is currently broken because of these changes. I'm happy to commit these changes I just want to know what it's fixing.

In D26137#580328, @lwhsu wrote:

Does this suppress D25425 and D25830?

LGTM

• rebase
• fix permissions

@oshogbo The kmod changes are going to be overwritten by this weeks merge, so it would probably be worthwhile to create a PR upstream. Thanks.

In D25872#578066, @linimon wrote:

Applying the diff and deleting the empty files was what got me to this point.

I suppose the only way forward is for me to learn git.

In D25872#577647, @linimon wrote:

This is as far as I was able to get:

> cddl/lib/libctf (obj,all,install)

[Creating objdir /usr/obj/tank/src/head/powerpc.powerpc64/tmp/obj-tools/cddl/lib/libctf...]
cc -O2 -pipe -fno-common -DCTF_OLD_VERSIONS -DIN_BASE -I/tank/src/head/sys/contrib/openzfs/lib/libspl/include/os/freebsd/spl -I/tank/src/head/sys/contrib/openzfs/include -I/tank/src/head/sys/contrib/openzfs/lib/libspl/include/ -I/tank/src/head/sys/contrib/openzfs/lib/libspl/include/os/freebsd -include /tank/src/head/sys/contrib/openzfs/include/os/freebsd/spl/sys/ccompile.h -DHAVE_ISSETUGID -I/tank/src/head/sys/cddl/compat/opensolaris -I/tank/src/head/cddl/compat/opensolaris/include -I/tank/src/head/cddl/lib/libctf/../../../cddl/contrib/opensolaris/head -I/tank/src/head/cddl/lib/libctf/../../../cddl/contrib/opensolaris/common/ctf -I/tank/src/head/cddl/lib/libctf/../../../cddl/contrib/opensolaris/lib/libctf/common -I/tank/src/head/cddl/lib/libctf/../../../sys/cddl/contrib/opensolaris/uts/common -DNEED_SOLARIS_BOOLEAN -g -MD -MF.depend.ctf_create.o -MTctf_create.o -std=gnu99 -Wno-format-zero-length -Qunused-arguments -I/usr/obj/tank/src/head/powerpc.powerpc64/tmp/legacy/usr/include -c /tank/src/head/cddl/contrib/opensolaris/common/ctf/ctf_create.c -o ctf_create.o
<built-in>:1:10: fatal error: '/tank/src/head/sys/contrib/openzfs/include/os/freebsd/spl/sys/ccompile.h' file not found

• Install zdb, zfs, and zpool man pages
• update rootgen.sh

Delete some more unused files

• Remove unneeded files
• Install libzfs.h and libzfs_core.h

Rebase and remove header in response to feedback

In D25530#564396, @gallatin wrote:

Why is it safe to just drop the lock?

What exactly is the LOR? I just see a stack.

update opensolaris module Makefile

-kern.pre.mk formatting feedback

• fix a dtrace makefile

• rebase
• add macro for dtrace makefiles

make s/current/curstate/g separate

incorporate kern.pre.mk and dtrace.c comment feedback

I'm a bit confused. The counter descriptions are just copied from Linux. If you're just copying from there, just add them as is. If you're doing something new then add them as a different file.

If you add a new file it won’t be overwritten by updates

In D24733#550888, @adrian wrote:

In D24733#550875, @mmacy wrote:

Sigh - this is why when I added the flowid we didn't set the hash for TCP - we relied on the result from the hardware ...

That's like 80% of the problem, the other 20% was getting the pcb into the right group early on and not have to go move it between the RSS buckets.

The flowid stuff is separate from RSS per se. If you use flowid without the microsoft style RSS with the per-CPU work distribution then yeah, you don't need the software hashing. But if you want to have it partition up the work early that also includes putting the pcb into the right RSS hashed pcbgroup, and that requires a software hash.

It's only done, like, once..

I have further changes.

Sigh - this is why when I added the flowid we didn't set the hash for TCP - we relied on the result from the hardware ...

YAY

LGTM

I can for the very near future, but as we get closer to replacing what’s in HEAD the burden should shift to the individual contributor to interact directly with upstream.

I don't see anything wrong with this review, but FYI there is now a live upstream https://github.com/openzfs/zfs/commit/9f0a21e6411aa0bac23fba0ddb220342a48c7cc7 and the code in HEAD will some time later this year be replaced with vendor code. Most of the changes to ZFS in HEAD at this point will only live on through MFCs to stable/12 and stable/11.

In D15010#468020, @mjg wrote:

Is this getting anywhere?