From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from tb-ob0.topicbox.com (tb-ob0.topicbox.com [64.147.108.117]) by inbox.vuxu.org (Postfix) with ESMTP id D5C9D22229 for ; Sun, 25 Feb 2024 02:01:52 +0100 (CET) Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob0.topicbox.com (Postfix) with ESMTP id 0193520CE1 for ; Sat, 24 Feb 2024 20:01:50 -0500 (EST) (envelope-from bounce.mMb935ad65e7512b2d0a6787a8.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id F11DDDA0568; Sat, 24 Feb 2024 20:01:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:references:in-reply-to:date:mime-version :content-type:content-transfer-encoding:list-help:list-id :list-post:list-subscribe:reply-to:from:list-unsubscribe; s= dkim-1; t=1708822909; x=1708909309; bh=hvZExhVYr+03l3yda264qLSr8 D5wRYAuEs72mIiqK80=; b=L9vUHRVkLDDb9ghmKwyl1HliiSE4FWfJ1NT88ep2C c1M7HadGp4sTOvQxcaN7fG2OVKBYBS6v3aqxqUj3VUw3/5rjgv8MRcee79EnV4Vy P4fDdHf1gFf8SsHaq986jDnhII/4gVfoiu/zL52UkoICzXZrZarVZXMLkOTmNO0l Ek= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] Re: Hello, RPi fixes and bind -b trouble Message-Id: <17088228990.2DDF4.31241@composer.9fans.topicbox.com> References: <17070592670.E7CF6327b.7700@composer.9fans.topicbox.com> <17070649110.Bb83425E.69346@composer.9fans.topicbox.com> <17070654320.9a2dd3.8938@composer.9fans.topicbox.com> <17070851850.5D4Acd.328289@composer.9fans.topicbox.com> <17086311280.67fcAA.82492@composer.9fans.topicbox.com> <4f3c46d8-d10e-4bf4-a6f8-376ee11bb0c0@posixcafe.org> <17086903380.CDcDB65.976941@composer.9fans.topicbox.com> <8acfd2f2-d802-4918-813f-4f903fb5453a@posixcafe.org> In-Reply-To: <8acfd2f2-d802-4918-813f-4f903fb5453a@posixcafe.org> Date: Sat, 24 Feb 2024 20:01:39 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17088228991.9Bf68.31241 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 6f004900-d379-11ee-a7b1-34f640decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UYmM3OGQyOWFiMDQ2NTJhMi1NYjkzNWFkNjVlNzUxMmIyZDBhNjc4?= =?UTF-8?B?N2E4Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> From: "Alyssa M via 9fans" <9fans@9fans.net> List-Unsubscribe: , Topicbox-Delivery-ID: 2:9fans:437d30aa-c441-11e9-8a57-d036212d11b0:522be890-2105-11eb-b15e-8d699134e1fa:Mb935ad65e7512b2d0a6787a8:1:DG2muruHLgFw58beGYLp0j9Rs5OIC3oojjU6TZdkSGs --17088228991.9Bf68.31241 Date: Sat, 24 Feb 2024 20:01:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well I had a go at this on my RPi. I altered libc.a to arrange that errstr(= ) removes the error string filename decoration, but print ("%r") doesn't, a= nd wrapped the open() call (as an example) to do its own error string decor= ation and hand that back to the kernel. Unfortunately I then looked in the kernel and discovered that namec (which = does the decorating) is called in about 50 places. If it stopped decorating= error strings, there are potentially a lot of places that would notice, an= d I haven't chased them all down. =C2=A0That being so, my enthusiasm for th= is idea is much dampened, and I think it's dipped below the worth-consideri= ng threshold. :( I'll keep the code I wrote around in case it's ever useful. On the plus sid= e, I learned some things about the libc.a build process. And the awesome mk= file in /sys/src/libc/9syscall. I think it would still be worth fixing exportfs to strip off any decoration= before sending out an error string via Rerror, though, as that would fix v= 9fs's problem and the nested mounts problem I was looking at earlier. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-Mb935a= d65e7512b2d0a6787a8 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17088228991.9Bf68.31241 Date: Sat, 24 Feb 2024 20:01:39 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well I had a go at this on my RPi. I altered l= ibc.a to arrange that errstr() removes the error string filename decoration= , but print ("%r") doesn't, and wrapped the open() call (as a= n example) to do its own error string decoration and hand that back to the = kernel.

Unfortunately I then looked in the= kernel and discovered that namec (which does the decorating) is called in = about 50 places. If it stopped decorating error strings, there are potentia= lly a lot of places that would notice, and I haven't chased them all do= wn.  That being so, my enthusiasm for this idea is much dampened, and = I think it's dipped below the worth-considering threshold. :(
I'll keep the code I wrote around in case it's ever useful. = On the plus side, I learned some things about the libc.a build process. And= the awesome mkfile in /sys/src/libc/9syscall.

=
I think it would still be worth fixing exportfs to strip off any decor= ation before sending out an error string via Rerror, though, as that would = fix v9fs's problem and the nested mounts problem I was looking at earli= er.

= --17088228991.9Bf68.31241--