Thanks for the detailed explanation, it is clear now.

For nitems it was out of curiosity, no strong opinion here.

OK with the const added.

On Wed, May 20, 2026, at 09:18, Alexandre Ratchov wrote:
> On Tue, May 19, 2026 at 04:42:57PM +0200, Jonathan Armani wrote:
>> Hello Alex,
>> 
>> Some questions / feedbacks inline but works fine.
>> 
>> OK
>> 
>> On Tue, May 12, 2026, at 12:01, Alexandre Ratchov wrote:
>> > ping
>> >
>> > ----- Forwarded message from Alexandre Ratchov <alex@caoua.org> -----
>> >
>> > Date: Sun, 15 Mar 2026 21:17:43 +0100
>> > From: Alexandre Ratchov <alex@caoua.org>
>> > To: tech@openbsd.org
>> > Subject: sndiod: Add the server.mode control making the server mode dynamic
>> >
>> > This diff allows the server mode to be changed at run-time with the
>> > new server.mode control exposed by sndioctl(1), ex:
>> >
>> > $ sndioctl server.mode=play,rec,mon
>> >
>> > Useful to record your screen with voiceover without restarting sndiod
>> > twice. The -m option defines its initial value.
>> >
>> > If the server is switched to play-only mode, then existing clients
>> > will start recording silence. Similarly if it's switched to rec-only
>> > mode, clients are muted. Connections are never dropped.
>> >
>> > At sndiod startup, trying to determine the hardware mode based on the
>> > -m options doesn't make sense anymore. So -m can no longer be used to
>> > force the hardware mode, which is not very useful these days imho.
>> 
>> Maybe worth a man update ?
>> 
>
> Hi,
>
> The way the hardware is open is not detailed in the man page, so the
> current text still applies. The -m option remains the "sub-device
> mode" even if it is not used to determine the hardware mode anymore.
>
>> > @@ -1473,12 +1458,6 @@ slot_attach(struct slot *s)
>> >  	struct dev *d = s->opt->dev;
>> >  	long long pos;
>> > 
>> > -	if (((s->mode & MODE_PLAY) && !(s->opt->mode & MODE_PLAY)) ||
>> > -	    ((s->mode & MODE_RECMASK) && !(s->opt->mode & MODE_RECMASK))) {
>> > -		logx(1, "slot%zu at %s: mode not allowed", s - slot_array, s->opt->name);
>> > -		return;
>> > -	}
>> > -
>> 
>> Where does server.mode is constrained to what hardware really support ? Not wanted ?
>>
>
> Programs are not constrained anymore, on purpose.
>
> Currently if the hardware can't play (ex. webcam's microphone), we
> allow clients to play but throw the data until the user switches to a
> capable device (ex. with the server.device control). This diff, simply
> extends this logic to the -m option and the server.mode control.
>
> Constraining (i.e. disconnecting) the client if the hardware lacks the
> capability would require to disconnect clients when server.device
> passes through a non-capable device (or server.mode temporarily
> disables one direction). This is unpractical because there's no way
> for the user to roll-back (disconnected programs may need to be
> restarted after server.device or server.mode change).
>
>> > 
>> > +struct opt_mode opt_modes[] = {
>> > +	{MODE_PLAY, "play"},
>> > +	{MODE_REC, "rec"},
>> > +	{MODE_MON, "mon"},
>> > +};
>> > +
>> 
>> const ?
>> 
>
> yeah, I'll fix that as rsadowski@ noted as well, thanks.
>
>> > @@ -486,19 +488,52 @@ opt_del(struct opt *o)
>> >  void
>> >  opt_init(struct opt *o)
>> >  {
>> > +	int i;
>> > +
>> > +	for (i = 0; i < sizeof(opt_modes) / sizeof(opt_modes[0]); i++) {
>> 
>> I don't ever remember if we have nitems ;D
>> 
>
> AFAIU, ntimes() would require including sys/param.h which we try to
> avoid. I guess that's why many programs define their own nitems()
> macro?
>
> sndiod has already many instances of "size(x) / sizeof(x[0])", let's
> handle them all in once in another diff.