From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED,
	T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4
Received: (qmail 15285 invoked from network); 20 Dec 2023 23:14:19 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 20 Dec 2023 23:14:19 -0000
Received: from wopr.sciops.net ([216.126.196.60]) by 9front; Wed Dec 20 18:11:01 -0500 2023
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sciops.net; s=20210706;
	t=1703113766;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:  in-reply-to:in-reply-to;
	bh=xeou0qVwURzAyACnKbiZ0Xil6k8iQIiFW5/CLj1q+eM=;
	b=wacIeBhCOB6vKf5/dMUBVLsInWdmA26k6BXQszB7anaeBjcp8JUtxsnar1xGgPnyTVoP8k
	zE8rPv+MfEPWvTMOd6GDYaOZf+Udogrj1lSUUsSWy7uMeB1JTbVFbcYtONWX87z468IXJC
	98p5PFDu9LKuORvBn9BDBZUQAU2weKw=
Received: 
	by wopr.sciops.net (OpenSMTPD) with ESMTPSA id f5514d3d (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO)
	for <9front@9front.org>;
	Wed, 20 Dec 2023 15:09:25 -0800 (PST)
Message-ID: <C3E191AE5BF9934F377F8AE5C2A2AE67@wopr.sciops.net>
Date: Thu, 21 Dec 2023 00:10:44 +0100
From: qwx@sciops.net
To: 9front@9front.org
In-Reply-To: <1235011938.3556150.1703098437964@comcenter.netcologne.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: lossless flexible markup module realtime extension 
Subject: Re: [9front] [PATCH] Fix nusb/audio /dev entries
Reply-To: 9front@9front.org
Precedence: bulk

On Wed Dec 20 19:54:05 +0100 2023, meyer.arne83@netcologne.de wrote:
> Hello qwx,
> 
> > qwx@sciops.net hat am 20.12.2023 17:44 CET geschrieben:
> > 
> > Thanks for the patch.  One could argue against the previous behavior
> > -- what is your use case?
> 
> I have a thin client with hda audio that is not quite working with the 9front driver. So
> I use a cheap usb sound card to get audio. In this case I could probably do
> 'unmount #A' in a namespace file and have it work as intended?

There's a few ways in which you can achieve this, but yeah I imagine
that something like `unmount '#A' /dev` at the right place is enough
for your purposes (eg.  /cfg/$sysname/termrc, $home/lib/profile,
etc.).  You can also disable the card in plan9.ini.  Of course, best
would be to fix the driver, but that's work.


> > What do you think, would that work in your case?
> 
> If I plug in a usb device I expect it to become the default device. Maybe mixfs
> can do some clever stuff here?

Maybe, but I'm not sure how that would work, and it would be a bunch
of additional code, when in reality the simplest thing you could do is
to unmount #A and #u and remount them in the opposite order, or in
your case, just unmount #A.  After the discussions I've had, I'm
leaning towards having the user configure this themselves (usually
this would be a one time setup), leaving a note about it in nusb(4).
So far, the people who have participated in the discussion have all
had somewhat different opinions about this, so imho it's not really
clear what the expected behavior would be for most.

Cheers,
qwx