In D55670#1276909, @christos wrote:

In D55670#1276620, @markj wrote:

In D55670#1276311, @christos wrote:

I'm thinking about this again and I'm suspecting this will make things very inflexible. I think that instead of patching virtual_oss, it might be better to have an environment variable that specifies the control device name, and let devd use that. @markj What do you think?

As I understand it, the basic problem is that virtual_oss is providing a virtual audio device, and there's an associated control device, and there is no mechanism to figure out the control device name from the audio device name, aside from looking at whatever's configured in rc.conf.

Can virtual_oss create files under /var/run which provide this mapping? Similar to a pidfile, it could create /var/run/virtual_oss.dsp at startup, and the file would contain the path to the control device. Then snd.conf would contain something like action "/usr/sbin/virtual_oss_cmd $(cat /var/run/virtual_oss.${cdev}) -R /dev/${cdev}". I'm pretty sure devd can perform substitutions like that, the devd.conf man page has an example of it.

The thing is that if we want to be flexible, we cannot know which control device the user wants to use. Perhaps the user wants to use a control device for a virtual_oss instance that does not replace /dev/dsp, hence why an environment variable that is easily modifiable might be simpler. Not sure yet.

I also tried to replace the TAILQ with STAILQ to avoid this line:

panic: /usr/src/sys/netinet6/nd6_nbr.c:1665: nd6_queue_rel: Bad link elm 0xfffff80028a00900 prev->next != elm

But the actual problem is the data is already freed and this is not just a consistency check failure from TAILQ (prev->next != elm).

Please look at the panic below produced by this patch when you have time.
I already reverted the delayed proxy address changes from the main branch, so this won't happen in production.
Honestly, delayed proxy addresses aren't that important.
However, it looks like we need to use a different lock to handle delayed proxy addresses.

Thank you!
@ocle done.

Yes, I like this version better.

In D55828#1277603, @pouria wrote:

In D55828#1277300, @zlei wrote:

Ah, I have WIP to fix the race condition between if_detach() and if_vmove(). See PR 292993 .

Oh, I was working on that problem too.
I thought you had seen D55777 earlier, you're on the reviewers list.
I can release the PR and assign it to you to avoid duplicating effort, if you want.

How about this? I think keeping the static_cast instead is more consistent with the rest of this source file.

I didn’t know about Coreboot until you posted this differential.

In D55828#1277603, @pouria wrote:

In D55828#1277300, @zlei wrote:

Ah, I have WIP to fix the race condition between if_detach() and if_vmove(). See PR 292993 .

Oh, I was working on that problem too.

In D55828#1277300, @zlei wrote:

Ah, I have WIP to fix the race condition between if_detach() and if_vmove(). See PR 292993 .

This is really awesome -- thank you for doing all of this work on the driver.

In D55819#1277553, @des wrote:

This, of course, assumes that neither the compiler nor the CPU reordered the writes...

Out of curiosity--since I no longer have any Apple IR remotes (my last one went away with my AppleTV back in the late 2010s), have you tried taking off the case and looking at the internal chips for identifying marks on any of the ASICs? I'm curious because it might help you figure out which NEC ASIC may or may not be compatible with this driver.

Does building/installing this driver on all platforms (TARGET/TARGET_ARCH) make sense?

I read through everything two different times, and convinced myself both times this is the proper change.

Don't use IOVEC_ADVANCE

Superseded by D55838

In D55819#1277146, @jhb wrote:

In particular, is the invariant you are tripping over QCMD_STAILQ_CHECK_TAIL?