One thing I did not try to address is the other places that define nvlist_t (notably in libcasper). They do so _after_ including <sys/nv.h> which is kind of confusing to me and I'm not sure why that is so I've left them alone.

In D48251#1100313, @emaste wrote:

Example from PR283238:

$ mkdir -p test9660/this-is-a-directory-with-a-long-common-prefix-1 test9660/this-is-a-directory-with-a-long-common-prefix-2
$ makefs -t cd9660 -o rockridge test.iso test9660/
$ isoinfo -p -i test.iso
Setting input-charset to 'UTF-8' from locale.
Path table starts at block 18, size 86
   1:    1 14 
   2:    1 15 THIS_IS_A_DIRECTORY_WITH_A_LON
   3:    1 16 THIS_IS_A_DIRECTORY_WITH_A_LON

With this:

$ isoinfo -p -i test.iso
Setting input-charset to 'UTF-8' from locale.
Path table starts at block 18, size 90
   1:    1 14 
   2:    1 15 THIS_IS_A_DIRECTORY_WITH_A_LON0
   3:    1 16 THIS_IS_A_DIRECTORY_WITH_A_LONG

Example from PR283238:

$ mkdir -p test9660/this-is-a-directory-with-a-long-common-prefix-1 test9660/this-is-a-directory-with-a-long-common-prefix-2
$ makefs -t cd9660 -o rockridge test.iso test9660/
$ isoinfo -p -i test.iso
Setting input-charset to 'UTF-8' from locale.
Path table starts at block 18, size 86
   1:    1 14 
   2:    1 15 THIS_IS_A_DIRECTORY_WITH_A_LON
   3:    1 16 THIS_IS_A_DIRECTORY_WITH_A_LON

Are there any other potential consumers of this interface, besides rfb? I see the comment that mentions why gdb can't participate, which is a bit unsatisfying but okay.

Handle the possibility of duplicate forwarding addresses.

In D48032#1096297, @dev_submerge.ch wrote:

In D48032#1096268, @christos wrote:

In D48032#1095744, @dev_submerge.ch wrote:

If you want to make your function equal to the macro in terms of performance, you have to call it with literal format parameters somehow. E.g. through a switch on the format parameters.

I do not have a benchmark right now to prove the opposite, but do you think such a performance hit is noticeable, if at all existent? Currently we use a function pointer to a specialized function (i.e one for each format), and the patch uses a generic function which fetches the format directly from the struct. I am not really well-versed with compiler optimizations, but I would suppose that the generic one is more likely to be inlined, and thus give us a performance boost (I did see the comment about CPU-branch prediction in D47932).

The function pointer prevents inlining, alright. But inlining your generic function doesn't help to optimize the inner loops in feed_eq_biquad() that dominate here. The macro did that.

The main rationale behind this patch, as well as the other similar ones, is to make the code cleaner and easier to work with. There had been a few times already where I tried to make some changes to these files (especially with AFMT_FLOAT support) and the macros make it quite tedious. Even though D47932 fixes most of what I wanted, I still think it's good to have clean code everywhere.

I'm not telling you to go back to macros. All you need is a switch on the format parameter, in a dispatch function between the caller and feed_eq_biquad(). Something like:

switch(info->fmt) {
/* Cases you want to optimize for. */
case AFMT_S16_NE:
        feed_eq_biquad(..., ..., ..., AFMT_S16_NE);
        break;
case AFMT_S32_NE:
        feed_eq_biquad(..., ..., ..., AFMT_S32_NE);
        break;
/* Generic fallback, less optimized. */
default:
        feed_eq_biquad(..., ..., ..., info->fmt);
        break;
}

In D47918#1100168, @dev_submerge.ch wrote:

In D47918#1100131, @christos wrote:

In D47918#1099644, @dev_submerge.ch wrote:

Not a consequence of your changes here, but it seems we only set the vchan settings on the first channel per direction. There could be multiple, right?

IIRC, there's only one or two sound drivers that support multiple channels per direction. Maybe we should evaluate whether that's actually required and worth the complication it causes throughout the sound module.

There are more places in pcm/ where we always pick the first primary channel. I guess we could implement some heuristics, like choosing the first non-busy channel, or else fall back to the first channel, or the channel with the least vchans, in order to balance things out, but that would require multiple changes throughout sound(4), so we could discuss this further in an email.

Just to clarify, my general proposal would be to see whether we can limit all drivers to at most one primary channel per direction. If that's possible, the primary channel list reduces to two fields (one per direction), and handling them should become easier in the places you mention. It's a separate discussion though, agreed.

My point regarding the code here is that we change settings for only one of the primary channels, while we should do this for all primary channels to keep them consistent. Which is an example of where it would be easier to have only one primary channel per direction.