virtual_oss: Introduce virtual_oss_default_control_device rc variable

[christos]

Summary

The -t option gives the user the ability to create a control device for
a given virtual_oss(8) instance, so that the instance's configuration
can be manipulated during runtime with virtual_oss_cmd(8). As is
expected, the control device's name is not known, since it is specified
by the user.

This patch introduces a virtual_oss_default_control_device rc variable,
which defaults to "vdsp.ctl". The goal of this is that third-party
programs and scripts can access the control device of the default
virtual_oss(8) configuration without guessing. This is especially useful
for sbin/devd/snd.conf which deals with hot-swapping sound devices using
virtual_oss(8).

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

[markj]

It's hard for me to understand what this change does, or the tradeoffs involved, without a commit log message.

[christos]

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?

[markj]

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.

[imp]

Devd knows the cdev for /dev/ nodes created for a limited number of events. For those, it can do what @markj suggests

[christos]

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.

[meka_tilda.center]

What about alternative approach as in "ask the /dev/dsp* what is its control device"? For hardware devices the answer is NULL, for virtual_oss, it's /dev/dsp.ctl (or whatever is configured). Or maybe get devices through nvlist and /dev/sndstat and see which devices are virtual. In any case, my idea is "ask the kernel". I don't have preferences on the exact implementation.

[christos]

In D55670#1276915, @meka_tilda.center wrote:

What about alternative approach as in "ask the /dev/dsp* what is its control device"? For hardware devices the answer is NULL, for virtual_oss, it's /dev/dsp.ctl (or whatever is configured). Or maybe get devices through nvlist and /dev/sndstat and see which devices are virtual. In any case, my idea is "ask the kernel". I don't have preferences on the exact implementation.

Still the point is to know which is the appropriate control device to use in third-party scripts/programs such as sbin/devd/snd.conf that does the automatic switching. Even if we did implement such a thing, it wouldn't solve this problem.

@markj Is there a reason an environment variable won't do the work? We give it a default value, say, vdsp.ctl, which is a common control device name, and let the user change it to whatever they feel appropriate. The only thing I don't like with this is that it introduces one more "variable". I want it this to be automatic, but I'm not sure how we can achieve that without a degree of hardcoding and limitation, like this patch here implements.

[markj]

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 don't understand the problem with my suggestion. Can you give an example where it doesn't work?

[christos]

In D55670#1277707, @markj wrote:

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 don't understand the problem with my suggestion. Can you give an example where it doesn't work?

At the moment we cannot assume two things: 1) which control device belongs to which virtual device, 2) which control device the user actually wants to use in, say, snd.conf. Issue 1 could indeed be solved with something like what you propose. Issue 2, however, cannot, because even if we have a virtual-to-control device mapping for each virtual device, we cannot assume which virtual device the user wants to manipulate. Sure, the most common use-case and predictable scenario is that the user wants to use whichever control device is associated with the virtual_oss-created /dev/dsp, since this acts as the system-wide default device. That being said, I'm not sure if relying on this assumption is robust enough. What do you think?

[christos]

In D55670#1277863, @christos wrote:

In D55670#1277707, @markj wrote:

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 don't understand the problem with my suggestion. Can you give an example where it doesn't work?

At the moment we cannot assume two things: 1) which control device belongs to which virtual device, 2) which control device the user actually wants to use in, say, snd.conf. Issue 1 could indeed be solved with something like what you propose. Issue 2, however, cannot, because even if we have a virtual-to-control device mapping for each virtual device, we cannot assume which virtual device the user wants to manipulate. Sure, the most common use-case and predictable scenario is that the user wants to use whichever control device is associated with the virtual_oss-created /dev/dsp, since this acts as the system-wide default device. That being said, I'm not sure if relying on this assumption is robust enough. What do you think?

Bump.

[markj]

In D55670#1277863, @christos wrote:

In D55670#1277707, @markj wrote:

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 don't understand the problem with my suggestion. Can you give an example where it doesn't work?

At the moment we cannot assume two things: 1) which control device belongs to which virtual device, 2) which control device the user actually wants to use in, say, snd.conf. Issue 1 could indeed be solved with something like what you propose. Issue 2, however, cannot, because even if we have a virtual-to-control device mapping for each virtual device, we cannot assume which virtual device the user wants to manipulate. Sure, the most common use-case and predictable scenario is that the user wants to use whichever control device is associated with the virtual_oss-created /dev/dsp, since this acts as the system-wide default device. That being said, I'm not sure if relying on this assumption is robust enough. What do you think?

I see, one can use rc.conf to configure multiple virtual_oss instances. (virtual_oss is not documented anywhere in rc.conf.5, which seems like a bug.)

I don't see a good way to handle it with the current scheme. I would maybe add a new rc.conf variable, virtual_oss_default_control_device, defaulting to "vdsp.ctl", and get the value of that variable in snd.conf using $(sysrc virtual_oss_default_control_device). Then make sure everything is documented in rc.conf.5.

[christos]

In D55670#1283732, @markj wrote:

In D55670#1277863, @christos wrote:

In D55670#1277707, @markj wrote:

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 don't understand the problem with my suggestion. Can you give an example where it doesn't work?

At the moment we cannot assume two things: 1) which control device belongs to which virtual device, 2) which control device the user actually wants to use in, say, snd.conf. Issue 1 could indeed be solved with something like what you propose. Issue 2, however, cannot, because even if we have a virtual-to-control device mapping for each virtual device, we cannot assume which virtual device the user wants to manipulate. Sure, the most common use-case and predictable scenario is that the user wants to use whichever control device is associated with the virtual_oss-created /dev/dsp, since this acts as the system-wide default device. That being said, I'm not sure if relying on this assumption is robust enough. What do you think?

I see, one can use rc.conf to configure multiple virtual_oss instances. (virtual_oss is not documented anywhere in rc.conf.5, which seems like a bug.)

I don't see a good way to handle it with the current scheme. I would maybe add a new rc.conf variable, virtual_oss_default_control_device, defaulting to "vdsp.ctl", and get the value of that variable in snd.conf using $(sysrc virtual_oss_default_control_device). Then make sure everything is documented in rc.conf.5.

I like this approach. Will implement it and update the diff soon.

[christos]

Use an rc variable instead.