Abandoning because it's already fixed.

In D47410#1137166, @ziaee wrote:

Hey Damjan. Are you still interested in this? Your latest patch is just removing those blocks. Please squash your commits into one and try remaking the patch. If not, please close this. Thanks for your submission!

In D46689#1083011, @thj wrote:

In D46689#1082245, @damjan.jov_gmail.com wrote:

This update:

• Makes EIM opt-in, off by default, although I still think this decision needs broader discussion, or even a vote.

To be clear your position is that eim should be on by default?

And this one adds more context to the patch.

This update also changes NG_NAT_UDP_EIM from 0x800 to 0x200.

This update:

• Makes EIM opt-in, off by default, although I still think this decision needs broader discussion, or even a vote.
• Adds "udp_eim" options to all the libalias uses: ipfw, natd, ng_nat, and ppp.
• Rewrites the man pages and header files so they are shorter and clearer.
• Man pages don't introduce new errors in igor.
• Uses PKT_ALIAS_UDP_EIM instead of PKT_ALIAS_ENDPOINT_INDEPENDENT.
• Renames the splay tree from "source" to "internal_endpoint" in the source code.
• Simplifies some conditions.

In D47410#1082152, @thj wrote:

Is there a reason this moves in the ordering of nat rules? We tend to aim for roughly alphabetical ordering if there isn't a reason for something different?

Moves the "endpoint-independent" section to come after "bitmask", so they're in alphabetical order.

Also fix the typo: "caues" -> "causes".

I also need to patch ipfw and natd with user-settable options for the new flag, before this patch is fully ready... I am busy so that will probably take a few more weeks.

This new version adds a flag that can be used to turn this feature on and off (it is on by default for greater compatibility), adds documentation to the header file and man page, and wraps lines at 80 characters.

In D34184#804474, @kib wrote:

I still want the answer about use of the kernel addresses for kqueue/eventfd. Generally we try to not introduce new interfaces that directly expose KVA, whatever silly the idea of KASLR is.

This is probably irrelevant now that D34756 added a more general way to retrieve advisory lock info.

Is this still relevant?
D34756 added a more general way to retrieve advisory lock info.

Thank you for your feedback. New versions of this patch are at:
https://reviews.freebsd.org/D34184
https://reviews.freebsd.org/D34323

Also:

• Add a kf_eventfd_addr field to kf_eventfd and populate it.

In D34090#771897, @emaste wrote:

Kernel changes needed for lsof to work using only user mode APIs,

Can you confirm that with the set of changes here and without use of kvm, lsof's full functionality is available?

Added kf_pipe_buffer_[in/out/size] fields to kf_pipe.

In D33277#752192, @kib wrote:

In D33277#752190, @markj wrote:

Why not a sysctl-based interface, where the fd is a component of the MIB? Then info for a specific fd can be grabbed from a different process.

There is already kern.proc.filedesc, and I highly doubt that somebody needs a path for individual fd of remote process.