In D15904#336884, @mat wrote:

Mmmm,

$ readelf --print-file-name -r /usr/bin/mktemp
readelf: unrecognized option `--print-file-name'

In D15706#336215, @micchie.gml_gmail.com wrote:

In D15706#336214, @jtl wrote:

In D15706#336213, @micchie.gml_gmail.com wrote:

In D15706#335628, @rwatson wrote:

In D15706#334870, @micchie.gml_gmail.com wrote:

In D15706#334711, @jtl wrote:

In D15706#334605, @rwatson wrote:

Didn't quite catch this before it was committed. This isn't really a destructor, it's a close notification. Rather than confuse matters, as sockets have UMA destructors as well, this should probably be so_notify_close.

Yes, I caught that when I asked the submitter about the placement of the "destructor". But, once I figured out it was a close notification, I should have changed the name. Mea cupla.

Before changing this, let me see if I can confirm what the Linux implementation does.

Thanks, it is intended to be equivalent to sk_destruct() callback in struct sock in Linux.

Is the Linux sk_destruct called on socket close, or on socket destruction? If we want an actual socket destructor, we can add one of those [instead / as well], called from the socket destructor function.

It is literally destructor, which is called when the final reference count drops to zero. So probably we should define so_dtor() as destructor (so keep the name) and call it after SOCK_UNLOCK() in sofree(). (in Linux it is invoked without locking socket).

Which behavior do you want? As @rwatson indicated, you can both have a destructor and a close callback.

Just the destructor behaviour should suffice, but let me come back soon after checking.

I confirmed that the destructor behavior i.e., invoke it after SOCK_UNLOCK() in sofree() as below.
Or should I submit a new patch?

This is somewhat orthogonal, but since you are makes the init the proper child of the proc0, shouldn't proc0 get the P_TREE_REAPER flag ? Otherwise, dying init would confuse the reaping code. We do allow init(8) to die sometimes, without inducing the panic.

Replace arg with semarg; And some minor changes

In D15791#336576, @bdrewery wrote:

Seems fine. What generated files are you talking about exactly?

In D15911#336740, @markj wrote:

In D15911#336659, @kib wrote:

This should be fine.

Can we return an indicator if the page freed from the locked pmap, and retry only in this case ?

We can. I implemented it this way originally, but found it a bit ugly, and strictly speaking we only need to retry if the chunk was freed from the locked pmap *and* it contained free entries. That is, even with your suggestion we may still retry when it is not necessary. If you prefer that approach I'll implement it instead, but I mildly prefer this patch because it's simpler than the alternative.

Could you use devel/arcanist, or at least generate a diff with full context like it does, with svn diff -x -U9999 or git diff -U9999.

Can you provide any test case for that?

Update as per comment.

Thanks.
I didn't know that it works through the Approved By value.

In D13416#336036, @yuri wrote:

Commit still fails:

Committing transaction...
svn: E165001: Commit failed (details follow):
svn: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
Do not commit a port with FLAVORS without first
getting approval from portmgr.

It seems to work fine on pine64-lts.
So when my comments are resolved I think you could commit this (with the patch I sent you for arm64).

I'm not sure if I object to this change or not, but it's worth noting that SSIDs are not necessarily UTF-8 strings. Unless the SSIDEncoding is set it is 0-32 octets. Having 0 bytes in the middle of the SSID is valid (though I'd be very surprised if that actually worked on more than a handful of devices). If SSIDEncoding is set it is indeed a UTF-8 string.
For additional fun Microsoft got this wrong and several Windows versions interpret the SSID as being Latin1 encoded.