DragonFlyBSD

Well, this is what I got. My solution is somewhat ugly, but let you be the judge.

fionbio_master.patch makes fcntl call an appropriate ioctl on the file pointer if O_NONBLOCK flag is requested (patch to sys/kern/kern_descrip.c)
All other changes to the kernel were made to ioctl implementations to make them return 0 (no error) if a corresponding device or whatever supports non-blocking mode. These specific implementations do not need to do anything on their own, so they just return 0. PCM subsystem, on the other hand, finally executes its ioctl call and does everything it needs to switch back to non-blocking mode.

To be sure, that this does not break anything, I wrote a set of tests that checks if O_NONBLOCK flag can be set to any of the typical descriptor types: kqueues, pipes, sockets, vnodes (including regular files, some character/block devices, klog device) etc. All of them must silently return if executed (maybe with exception of klog, as you may have not permissions to open /dev/klog).

There is test_dsp.c in the set to test pcm subsystem. It must play 6 second silence and silently quit.

This patch checks ap->a_ioflag from dsp_read() and dsp_write()'s function argument for the O_NONBLOCK flag (after passing it through several layers of function calls). The CHN_F_NBIO flag that is internally kept by the sound subsystem (and displayed when doing cat /dev/sndstat after setting the hw.snd.verbose sysctl to some value >=2) is accordingly updated on each read/write call.

I had linked to this patch in the irc channel ca. 1 Month ago, and now I'm no longer sure if checking ap->a_ioflag for the O_NONBLOCK bit is actually correct. Most other drivers seem to check ap->a_ioflag for the IO_NDELAY bit instead.

fixed by bb3a8342e9142d9204404a9e99d2c469a7dbf83f