Exp-run came back clean https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275370 so I've updated for a Monday commit.

• actually export the symbol...
• update doc date in manpage
• ZFS changes were merged from upstream

Compiled and minimally smoke tested on an amd64 world without sbrk support.

Compiled, but untested on an amd64 system without sbrk.

Compiled but untested on an amd64 world without sbrk.

Compiled, but untested on an amd64 world without sbrk.

Compiled, but not tested on an amd64 world without sbrk support.

Compile tested only on an amd64 userspace without sbrk.

I've built and tested this to the level of running hello world on an amd64 build without sbrk.

This change compiles against an amd64 build without sbrk, but I don't know how to test it.

Bump PORTREVISION

I see no reason to change the system call numbers when there is no ABI change. You'll need to add entries to lib/libc/include/compat.h to expose the old symbols under the right version for compatibility.

In D42914#978872, @kib wrote:

Are you sure about amd64? There is the arch-specific manually written vfork.S.
Does the patch rely on vfork.S in MD directory to override vfork.s automatically generated for the syscall?

I tend to think that decoupling them is a bit of a failure given that our update mechanisms tend to be all or nothing, but this looks like a nice improvement.

Remove NOASM additions

I've chosen to retain the git config change and not do chown of the source tree (only one of them is required). IMO it's useful to test with a read-only tree to since any such write is a bug in the normal build process.

Use pw useradd -m

This commit message is a lie in that it only exposes the next problem https://cirrus-ci.com/task/5157804504252416?logs=package#L4435

break(2) was never public, don't start now

Make _brk, brk, and sbrk compat symbols

• Move sbrk/sstk syscall removal to D42872
• Rebase

In D42862#977823, @kib wrote:

I am fine with marking sbrk as compat14, but it should be done consistently everywhere, i.e. include the implementation.

I'm not set up to test this, what's there is obviously broken...

D42862 is my preferred alternative (plus a patch I've not published to fix the tests)

I won't attempt to block this change, but I don't like it. break/sbrk is an awful interface and can't be fixed. IMO we're better off without it.

In D41421#977198, @minsoochoo0122_proton.me wrote:

In D41421#977186, @brooks wrote:

In D41421#977182, @minsoochoo0122_proton.me wrote:

How does jemalloc 5.3.0 handle when alignment is 0

jemalloc follows the illumos way of handling alignment when it is zero, whereas the current FreeBSD and glibc returns memory space using malloc(). If we are okay with this compatability issue, this can be landed to 15-CURRENT branch. I think 12-STABLE, 13-STABLE, 14-STABLE should stick with jemalloc 5.2.1 to keep the compatability with FreeBSD's memalign.

Any ideas?

IMO the only reason to support memalign is to be compatible. We should do what glibc does regardless of its official documentation.

I totally agree with that point, but I'm not sure how we can implement memalign exception and maintain it in future releases of jemalloc. This might cause confusion to some users who are already using jemalloc in other projects or systems because they know FreeBSD uses jemalloc, but we're making an exception here.

If we are going make this exception, what would be the best way to implement it? Should I patch je_memalign() thorugh FREEBSD-diffs?

In D41421#977182, @minsoochoo0122_proton.me wrote:

How does jemalloc 5.3.0 handle when alignment is 0

jemalloc follows the illumos way of handling alignment when it is zero, whereas the current FreeBSD and glibc returns memory space using malloc(). If we are okay with this compatability issue, this can be landed to 15-CURRENT branch. I think 12-STABLE, 13-STABLE, 14-STABLE should stick with jemalloc 5.2.1 to keep the compatability with FreeBSD's memalign.

Any ideas?

Comments on c605eea952146348e5e1ad5cab6c127d7a1bd164 suggest this will need an exp-run.