This function is set only in the EVFILT_READ case in dsp_kqueue(), so I suppose it is redundant to check for kn->kn_filter == EVFILT_READ here? Same for dsp_write_filter().

Or can kn->kn_filter have a different value?

From the man page description of the f_event method, I am not really sure what we want to store here. Is there a particular reason you chose sndbuf_getallocsize()?

I saw what SNDCTL_DSP_GETOSPACE does and did the same.

The EXAMPLE_POLL case waits on POLLIN, but here we arm the EVFILT_WRITE event. It feels like it should be EVFILT_READ instead?

Better to have this above sys/soundcard.h, as per style(9).

Why do we call knlist_remove() only when CHN_F_DEAD is not set, but dsp_kqfilter() calls knlist_add() unconditionally? This is not a hint to remove the check, but to understand why the check is here in the first place.

According to kqueue.9:

The kn_data value should be updated as necessary to reflect the current value, such as number of bytes available for reading, or buffer space available for writing.

Here we assign kn_data to an errno value instead. Shouldn't we assign it to 0?

Doesn't a return value of 1 indicate that there was no error?

You can assign this to 0 here and avoid setting it to 0 below for every case.

I do not think that cdevpriv pointer is ever set for the context of the kqueue read or write filters. You should have enough context in the knote itself to fetch everything needed to check for the filter conditions.

Extra empty line

If that's the case, kn_hook in dsp_kqfilter() can just be the cdevpriv and we can then fetch the appropriate channel here through it. We do the same in dsp_read() and dsp_write().

I thought that if channel was dead, it already detached the queue. I would need to think about how to test this.

If you look at kqueue(2) example, there is

if (tevent.flags & EV_ERROR)
    errx(EXIT_FAILURE, "Event error: %s", strerror(event.data));

So I think this works according to kqueue specs.

No, it indicates if knote is still valid or not. That's how cuse does it, hence virtual_oss behaves the same.

@kib Is there some kind of mismatch between kqueue.9 and kqueue.2, or do I just misunderstand something? Because kqueue.9 does not specify that, as I mentioned above.

I am not 100% sure I understand what kqueue.2's RETURN VALUES section tries to say to be honest, as in, I do not really get when we should return -1 and when !0.

I had much problems figuring out how to add kqueue support and as virtual_oss uses cuse, I used cuse's implementation of kqueue support as reference. In the process I did add my notes to kqueue(9) in a separate branch in my github fork. One of my goals of this implementation is to make that man page better, but one thing at a time.

Can you say exactly which sentences from kqueue.2 and kqueue.9 contradicts each other?

That said, neither of man pages ever states that knote f_event returns an error. f_event should return 0 for inactive knote, and non-zero if knot was activated somehow.

My comment about mismatching (not contradicting) statements between kqueue.2 and kqueue.9 is above, it does not refer to here. kqueue.9 says that kn_data holds the value of available bytes for reading/buffer spacing available for writing, but kqueue.2 shows event.data holding an errno value in case of an error, but this is not documented in kqueue.9.

Practically filters never return errors. And definitely they do not set EV_ERROR, I would be curious to see an example. EV_ERROR is described conscientiously in kqueue.2.

The reason why filters do not need to return error is because registered knotes must be torn down before the object they monitor is destroyed. If the object is lingering in error state, there is simply nothing to report, so knotes should be not activated.

When a knote is activated, then kn_data become something that knote set according to the semantic of its filter.

Is it actually possible to have !DSP_REGISTERED() here? Shouldn't we have drained knotes by that point?

This function should be structured so that this default case can't happen. dsp_kqfilter() can set kn->kn_ptr.p_v = ch and then this function can obtain the channel directly.

kn_data shouldn't be abused to return an error number. You can use kn_fflags to return this instead, if it's necessary. More standard would be to set EV_EOF and return 1, I suspect.

Good point.

Looking again into this, I suppose this case already cannot happen since dsp_kqfilter() won't add a knlist for the default case, right?

I was actually saying the same thing in previous comments (see right above).

Also since we can remove the DSP_REGISTERED() check, we can instead pass the channel to kn->kn_hook now.

Do we have good docs on what to return when hardware dies? I've seen a mix of ENXIO and ENODEV and kinda think the former is better since the latter indicates it's not supported (or so the error message says, with these in-kernel protocols, it's hard to say for sure). But I also know that's a storage-centric view since that's what we do there when the device is gone and is in a state where it can't come back.