With this set of changes (plus D15438) i386 netstat and sockstat binaries work on amd64.

And what is the scope of the ABI breakage ? I suspect that user programs like squid are affected.

In D15386#325723, @kib wrote:

And what is the scope of the ABI breakage ? I suspect that user programs like squid are affected.

I don't have a way to determine what all is broken. It's worth noting that we've already broken these ABIs in 12 with rS315662 and follow on commits. I probably wouldn't have proposed this change otherwise, but one more break and this fairly small change eliminates the need for a compatibility shim for freebsd32 (and also CHERI).

Exp-run completed without new errors (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228301).

Anyone on transport care about this?

In D15386#330028, @brooks wrote:

Anyone on transport care about this?

Yes, people in the transport group probably do care. (At least, they usually care about this sort of thing. :-) )

I'll add it to the agenda for our bi-weekly meeting tomorrow. Or, if we don't get the right people tomorrow, you can probably get a good answer at the Transport Working Group at the BSDCan Dev Summit next week.

I'm fine with the SCTP related changes.

Rather than using raw integer types, I wonder if we should introduce new FreeBSD types -- e.g., ksize_t, kptr_t -- that wrap them, instead? They would still all map through to int64_t/uint64_t as required, but if we needed to change this in the future, we could do so more easily.

(This would also allow us to more easily grep for kernel sizes and pointers exposed to userspace..)

In D15386#334600, @rwatson wrote:

Rather than using raw integer types, I wonder if we should introduce new FreeBSD types -- e.g., ksize_t, kptr_t -- that wrap them, instead? They would still all map through to int64_t/uint64_t as required, but if we needed to change this in the future, we could do so more easily.

Yes please! It also makes it clearer what type you're trying to get and makes errors more obvious if have the wrong one.

In D15386#335530, @brooks wrote:

• Use new ksize_t and kptr_t instead of (u)int64_t.
• Adjust some padding.

Hmm. This is the problem with thinking overnight on things. Do you think it should be kvaddr_t rather than kptr_t?

In D15386#335779, @rwatson wrote:

In D15386#335530, @brooks wrote:

• Use new ksize_t and kptr_t instead of (u)int64_t.
• Adjust some padding.

Hmm. This is the problem with thinking overnight on things. Do you think it should be kvaddr_t rather than kptr_t?

Yeah, I almost change to kaddr_t half way through. I'll switch to kvaddr_t.