I have been testing this again recently, and it works fine, at least with the tests I ran. I think we should go ahead and get it into the tree, it's been sitting in review for 3 years almost. releng/15.0 is branched so there is no fear of breaking the release, even though this shouldn't break anything in the first place, it's a kinst-specific change and at worst it won't always yield 100% correct results. Once we have it in tree we can work on remaining issues, but I do not see a point in keeping it here anymore.

The test patch should be a separate commit. You can link to it here in the "Test Plan" section (click "Edit Revision" and you'll see it). But I'm starting to think this is becoming more of a test program than an example one. Maybe we should think about it moving it to tests, and making some more straight-forward ones for /usr/share/examples.

All the comments in dsp_read_filter() apply to dsp_write_filter() as well.

@arrowd Is it ready?

The short MFC time is so that it can land in BETA1.

In D53020#1211354, @arrowd wrote:

Doesn't virtual_oss rc script already contain BEFORE: sndiod? This forms a cycle.

Address des@ comments.

In D53019#1211342, @des wrote:

The correct way to express that you need the network to be up is REQUIRE: NETWORKING.

In D53019#1211338, @des wrote:

While here, require DAEMON as well.

Why?

Perfect. :-)

In D52593#1207065, @arrowd wrote:

Builds fine on CURRENT and 13.5

Approved by the committee.

Use proper __FreeBSD_version value. I have the stable/15 MFC ready for
commit, with __FreeBSD_version bumped to 1500066.

I would like to land this today.

In D52593#1206348, @arrowd wrote:

LGTM, but I did not test this in Poudriere. @christos let me know if you want me to do it.

I will bump stable/15's __FreeBSD_version once I MFC virtual_oss to stable/15 in the next days, and will update the port here accordingly.

In D52365#1206292, @arrowd wrote:

All right then, all three ports build fine in Poudriere.

In D52365#1206282, @arrowd wrote:

In D52365#1206280, @christos wrote:

This is what we are doing already: https://cgit.freebsd.org/src/tree/usr.sbin/virtual_oss/virtual_oss/main.c#n1639

Or do you mean something else?

Yes, I mean that we can compile voss_sndio.so as part of the base build if it wouldn't need to link with libsndio.so directly. Replacing direct calls with dlsym'ed ones will untie voss_sndio.so from voss_sndio.so and all these ports would be unnecessary.

In D52365#1206279, @arrowd wrote:

In D52365#1206276, @christos wrote:

I suppose if I MFC changes to releng/15.0 and stable/15 we should be safe? This way all releases will share the same code.

I don't think so. The builder might run 15.0-p0 and not getting any updates. And picking something into the releng branch isn't enough - it should go through some releng process, AFAIK.

If ABI guarantees can't be held, we should look into calling sndio via dlopen/dlsym to move the dependency to the run time.

In D52365#1206153, @arrowd wrote:

This leaves us with a requirement for the ABI compliance. @christos would it be possible to guarantee backward ABI compatibility for the OSS bits in base, so that ports compiled against 15.0 sources would work with 15.1 binaries?

I'm going to commit this today and also MFC it to stable/15 before 03.10 00:00 UTC (releng/15.0) as suggested by @cperciva, along with the virtual_oss patches. There are a few things that need addressing but I think it's not a problem to work them while in tree.

15.0 is approaching, so I think we can go ahead and commit and work some of the issues I raised lately while in tree?

Address Ed's comment.

If it builds fine and there are no further issues I think we can commit it.

Address Ed's comment.

In D52308#1205072, @emaste wrote:

ld: error: unable to find library -lprivatesamplerate

Does @emaste 's suggestion in the inline comment fix this?

My comment is related to this, but I'm still getting this as well, looking..

In D52308#1204955, @arrowd wrote:

I'm still getting

===> lib/virtual_oss (all)
===> lib/virtual_oss/null (all)
make[6]: /usr/obj/usr/src/amd64.amd64/lib/virtual_oss/null/.depend:1: ignoring stale .depend for /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libprivatesamplerate.a
Building shared library voss_null.so
cc -target x86_64-unknown-freebsd16.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin  -Wl,-zrelro    -fstack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings -Wl,--warn-shared-textrel  -o voss_null.so.full -Wl,-soname,voss_null.so null.pico  -lprivatesamplerate 
ld: error: unable to find library -lprivatesamplerate

when trying to build this diff. It also does not apply with arc patch for me for some reason.

Address commnets. Also got the script to an acceptable (better) state with the
help of Mateusz (0mp@) and shellcheck(1).

In D52308#1203289, @cperciva wrote:

In D52308#1201895, @christos wrote:

The patch is essentially finalized and IMHO ready to commit. Only thing remaining (but not really that important) are the rc script inline comments.

Also, since I'd like this to land in 15.0, I guess we'd need to bump __FreeBSD_version for stable/15, so that ports like D52593 can build only if the machine does have virtual_oss in base (related discussion there). @markj @emaste @cperciva What do you think?

Yes, go ahead with the __FreeBSD_version bump. But please get it done soon; I'll be creating releng/15.0 in 1.5 weeks and this probably can't go in after that point.

I'm not sure if this compiles (see inline comment), but in any case, I will test the patch tomorrow. If you do not have a commit bit, I will also take care of it, and make sure it's MFC'd.

In D52509#1202341, @damjan.jov_gmail.com wrote:

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?

This corrupts memory and is a possible security exploit: zero-filling a smaller 32 bit struct with sizeof(larger 64 bit struct) zeroes, will writes zeroes beyond the end of the struct.

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?

In D52365#1202021, @arrowd wrote:

Sorry, ENOTIME. I will try to go over all the oss stuff this Sunday.

The patch is essentially finalized and IMHO ready to commit. Only thing remaining (but not really that important) are the rc script inline comments.