In D44792#1020926, @bz wrote:

Does this give any information pciconf -l would not already give? I would rather we'd improve our tooling than use a sysctl for that? I'd almost want something like ifconfig -g bridge -l in devctl or somewhere appropriate?

% pciconf -l | grep ppt
ppt0@pci0:2:0:0: class=0x028000 rev=0x1a hdr=0x00 vendor=0x8086 device=0x2723 subvendor=0x1a56 subdevice=0x1653

Maybe if the commit message would describe why this is helpful anyway, it would help to understand the problem it is trying to solve?

In D44792#1020920, @markj wrote:

Isn't this basically the same as pciconf -l | grep ppt?

Fix style.

Test

Add commit message.

The 2 month MFC is because e8c0d15a64fa will also be MFC'd in 2 months.

Address Mark's comments.

@meka_tilda.center Let me know when you test it. I think this should fix your virtual_oss returning EBUSY as well.

Re-opening since D44411 seems to be fixed.

Re-opening the review. Apparently the patch introduced a regression where where
dsp_[get|set]_flags() would fetch the flags of the wrong softc, resulting in
generally strange behavior if the machine had more than 1 audio device attached
(EBUSY's from dsp_open() etc). Get rid of dsp_[get|set]_flags() as they are no
longer needed and use pcm_[get|set]_flags() directly.

In D44570#1018022, @dev_submerge.ch wrote:

Hacked it into the sosso test executable to exercise this ioctl, I'm still not convinced of its utility. This lets every application of all users set the device description globally. I think it's useful on a system level (mixer or similar tool), but I'd be wary to use it in an application. For the purposes mentioned in OSSv4, something like virtual_oss can set the description of the pcm devices it creates in a different way.

Address manu's comments.

Address Mark's comment. Sorry for this.

Address Mark's comment.

In D44570#1016366, @dev_submerge.ch wrote:

Do you have a particular interest in this ioctl?

Address Mark's comments. NUL-terminate the input string in general, but also
NUL-terminate it right before we encounter a non-isprint() character (or do we
want to return EINVAL in this case?)

@dev_submerge.ch @emaste Do you think this is good to go?

In D44411#1016019, @dev_submerge.ch wrote:

"Good news", I can reproduce the lock order reversal on the main branch, without this patch - it's not related to the changes here. How should we proceed with that?

After thinking a bit more about it, and taking the comments into consideration, I think it's better to abandon this to avoid any unwanted side-effects and instead just focus on the userland tool.

In D44553#1015947, @markj wrote:

Isn't this backwards incompatible? If a caller sets the sysctl in C, they'll have to change the type of the variable that they use. Existing code will misbehave.

In D44546#1015789, @dev_submerge.ch wrote:

This is definitely more readable, but my main concern would be that this form of output is quite lengthy and not very grep-friendly. Imagine 8 pcm devices with 4 channels each (when idle). Ideally, we could easily grep for the whole output of a single device, or check which output is used by an application (cat /dev/sndstat | grep mpv). Would be handy for both personal use and bug reports from users. Or maybe we can integrate these selective queries into a user space tool?

Diff against main.

Fixed kern_poll() panic. Depends on D44544.

In D44411#1015557, @dev_submerge.ch wrote:

My first round of tests was all good, no regressions so far. I still have to test mmap'ed operation, probably tomorrow.

Do we have any systematic tests yet to check the whole OSS API? Or at least the most common ioctls?

D43545 takes care of this change. Should we close this?

Apply on top of D44411.