Sorry. This patch fixes the audio_errinfo32 typos.

This patch also uses C standard names for struct field types, and properly initializes and copies fields to audio_errinfo32.

This patch also uses fixed-width types for the 32 bit structs.

Thank you for the feedback. This new patch:

• Moves the 32 bit structs from sys/soundcard.h to dsp.c.
• Uses tabs for indentation.
• _IOC_NEWTYPE is used instead of repeating the ioctl definitions with the new type.
• Removes snd_sync_parm32 and AIOSYNC32, because snd_sync_parm and AIOSYNC are not really implemented.
• Only converts from 32 to 64 bit on AIOSFMT32, not on AIOGFMT32 where it was unnecessary.
• Converts from 32 to 64 bit on AIOGCAP32, unlike before, because all-zero fields have a meaning to the ioctl.

In D52509#1202168, @christos wrote:

This is just a quick draft, haven't tested that so take this with a grain of salt, but I guess something like this could work?

			audio_errinfo *ei = (audio_errinfo *)arg;

			bzero((void *)ei, sizeof(*ei));

If this is what you meant, it does seems considerably longer and uglier, for example:

If we did this:

This patch makes a number of improvements:

• The 32 bit structs are moved to sys/sys/soundcard.h, similar to struct sndstioc_nv_arg32 in sys/sys/sndstat.h (although most COMPAT_FREEBSD32 code in the kernel doesn't add 32 bit structs to header files, so why are we?).
• _IOC_NEWTYPE is used instead of repeating the ioctl definitions with the new type.
• The dsp_ioctl() function stays unchanged, instead a wrapper function dsp_ioctl_compat() does data conversions before and/or after calling dsp_ioctl(), for the structs that need conversion. This also has the benefit of better performance, as all the conversion is done outside of the locking done by dsp_ioctl(). And it's much cleaner, only a single COMPAT_FREEBSD32 ifdef is used.
• I've removed snd_sync_parm32, because even snd_sync_parm is not really implemented.
• Lines wrapped to 80 characters.

I agree, clearing CHN_F_NBIO in dsp_close() would be better. When debugging, if a closed channel has CHN_F_NBIO set, which then mysteriously disappears when it's re-opened, it could be confusing.

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.