sound: Simplify logic in dsp_io_ops()

[christos]

Summary

Use CHN_LOCK()/CHN_UNLOCK() directly, instead of
dsp_lock_chans()/dsp_unlock_chans(). These functions are useful when we
want to potentially lock both channels. Here we know which channel we
are locking, so we can just lock it directly. This way we get rid of the
prio variable as well.

Related to runpid again, there is no reason to assign it when
CHN_F_RUNNING is not set. channel->pid (as well as channel->comm) is
always assigned in dsp_chn_alloc().

Get rid of runpid. I do not see how we can end up with channel->pid
(td->td_proc->p_pid) not matching buf->uio_td->td_proc->p_pid.

Improve errno values.

not matching

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

[kib]

What is channel->pid? Where is it got assigned?

[christos]

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

[kib]

In D53736#1227757, @christos wrote:

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

This is not what I am asking about. Why do you need to save the pid, and how do you use it?

[christos]

In D53736#1227774, @kib wrote:

In D53736#1227757, @christos wrote:

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

This is not what I am asking about. Why do you need to save the pid, and how do you use it?

Both the pid and process name are mostly cosmetic, and are used in sndctl(8), /dev/sndstat and in some OSSv4 structures. It is just so that the user can easily tell which channel(s) belong to which processes.

[kib]

In D53736#1227776, @christos wrote:

In D53736#1227774, @kib wrote:

In D53736#1227757, @christos wrote:

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

This is not what I am asking about. Why do you need to save the pid, and how do you use it?

Both the pid and process name are mostly cosmetic, and are used in sndctl(8), /dev/sndstat and in some OSSv4 structures. It is just so that the user can easily tell which channel(s) belong to which processes.

So for instance, sharing the open file after fork, or passing it over unix domain socket, cause only a cosmetic issues, right?

[christos]

In D53736#1227777, @kib wrote:

In D53736#1227776, @christos wrote:

In D53736#1227774, @kib wrote:

In D53736#1227757, @christos wrote:

In D53736#1227693, @kib wrote:

What is channel->pid? Where is it got assigned?

From the commit message:

channel->pid (as well as channel->comm) is always assigned in dsp_chn_alloc().

I will correct the message to say pcm_channel->pid, which is the actual struct's name.

This is not what I am asking about. Why do you need to save the pid, and how do you use it?

Both the pid and process name are mostly cosmetic, and are used in sndctl(8), /dev/sndstat and in some OSSv4 structures. It is just so that the user can easily tell which channel(s) belong to which processes.

So for instance, sharing the open file after fork, or passing it over unix domain socket, cause only a cosmetic issues, right?

Yes.