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-ob1.topicbox.com (tb-ob1.topicbox.com [64.147.108.173]) by inbox.vuxu.org (Postfix) with ESMTP id C3E8D25EB6 for ; Fri, 23 Feb 2024 13:12:29 +0100 (CET) Received: from tb-mx1.topicbox.com (tb-mx1.nyi.icgroup.com [10.90.30.61]) by tb-ob1.topicbox.com (Postfix) with ESMTP id 723602A581 for ; Fri, 23 Feb 2024 07:12:28 -0500 (EST) (envelope-from bounce.mM000b059a9ae286c6ee128aea.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx1.topicbox.com (Postfix, from userid 1132) id 74EF7D7FA4F; Fri, 23 Feb 2024 07:12:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to:subject :message-id:in-reply-to:references: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=1708690348; x=1708776748; bh=a/egbg0HLmXsV8rvWjWpVtTSq 535y7J2wnXQY9oyyvA=; b=b2W87w/2veXgrT4E1brSur0kc/1xhbLFh/TH4WEXD qj+37VW6Q3d9mWj4f86ujnLAOXkZZV38NvB33aFaWPeGuIUHgZjanKgmEYzUY16D 74rW/0FKIMG+BdF0qKc/5vJa+PhKbWdlcDz+SyZF7jEOaZH4cAAg0aQY/sH0TPC1 cE= To: 9fans <9fans@9fans.net> Subject: Re: [9fans] Re: Hello, RPi fixes and bind -b trouble Message-Id: <17086903380.CDcDB65.976941@composer.9fans.topicbox.com> In-Reply-To: <4f3c46d8-d10e-4bf4-a6f8-376ee11bb0c0@posixcafe.org> 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> Date: Fri, 23 Feb 2024 07:12:18 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17086903381.aee3ce.976941 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: caa43b44-d244-11ee-aafc-cdda202d11b0 Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UYmM3OGQyOWFiMDQ2NTJhMi1NMDAwYjA1OWE5YWUyODZjNmVlMTI4?= =?UTF-8?B?YWVhPg==?= 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:M000b059a9ae286c6ee128aea:1:dMv12Jkun3QUZvb-_3XQhtQ4V7KNV2w6d710M-BmnCo --17086903381.aee3ce.976941 Date: Fri, 23 Feb 2024 07:12:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (Lucio posted while I've been thinking/composing/trying things...) Thanks for putting up with me! I confess I've been thinking about this a bit more, as something about this= doesn't feel right: =20 As I understand it, the kernel is getting an error string from some file se= rver, and is decorating it with a filename/pathname for the benefit of the = user, then returning it to userspace through errstr(2). exportfs(4) is then sending the decorated error string out to whatever moun= ts it. But, another machine that mounts that exported file system will then decora= te it a second time... If that composite file system is exported to a third= computer, then that system will mount it and its kernel will decorate it a= third time... This being plan 9, you can do this all on the same machine, so I tried it. In each=C2=A0 window I typed/snarfed/pasted something like: term% srv tcp!themachine!9123 step1 term% mount /srv/step1 /power term% aux/listen1 -t tcp!*!9124 /bin/service/tcp5564 (/power is just a handy unused directory to mount on. ;)) /bin/service/tcp5564 above is: #!/bin/rc exec /bin/exportfs -r / I created 3 windows, each mounting a composite file system exported from th= e previous one (by advancing the port numbers and srv names I used above). = And sure enough, the error message strings get longer and longer! Eventually I got: term% echo >/lib /fd/0:10: > can't create: lib: is a directory: './power/lib': './power/powe= r/lib': './power/power/power/lib': 'lib' I had to generate an 'is a directory' error to see this, rather than a 'fil= e not found' error, as the latter seems to get treated a bit differently, a= nd doesn't show this concatenative effect. This seems a bit daft. I was thinking that maybe exportfs should be stripping off the filename dec= oration after all: I'm not sure I can think of a scenario where sending it = through Rerror is helpful.=20 but this still doesn't feel right. exportfs is having to remove a decoration on an error string that the kerne= l added for the benefit of the user. I think the kernel should probably not= be doing this. The outcome is nice, but maybe it would be better if it wer= e done in libc, perhaps in the implementation of %r. Maybe the system call = functions in user space could record the pathname in a global buffer when a= n error occurs, and %r could use that.=20 Exportfs could then forward the error string without the kernel decorating = it, and we could leave Linux v9fs alone. Would that be better? Although English is my first language, I live among people for whom it most= ly isn't, so I see these issues every day. There's definitely a tension bet= ween the obvious practicality of using English as a "Lingua Franca" and not= wanting to lose other languages, which is important to some people. The wh= ole internationalisation thing is complicated and political, and thus hopef= ully something we can ignore here most of the time! I probably shouldn't ha= ve mentioned it.=C2=A0 :D=20 ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M000b0= 59a9ae286c6ee128aea Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17086903381.aee3ce.976941 Date: Fri, 23 Feb 2024 07:12:18 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Lucio posted while I've been thinking/com= posing/trying things...)

Thanks for puttin= g up with me!

I confess I've been thin= king about this a bit more, as something about this doesn't feel right:=

As I understand it, the kernel is getting= an error string from some file server, and is decorating it with a filenam= e/pathname for the benefit of the user, then returning it to userspace thro= ugh errstr(2).
exportfs(4) is then sending the decorated er= ror string out to whatever mounts it.

But,= another machine that mounts that exported file system will then decorate i= t a second time... If that composite file system is exported to a third com= puter, then that system will mount it and its kernel will decorate it a thi= rd time...

This being plan 9, you can do t= his all on the same machine, so I tried it.
In each  = window I typed/snarfed/pasted something like:
term% srv tcp= !themachine!9123 step1
term% mount /srv/step1 /power
<= /div>
term% aux/listen1 -t tcp!*!9124 /bin/service/tcp5564
<= div>

(/power is just a handy unuse= d directory to mount on. ;))

<= div>/bin/service/tcp5564 above is:
#!/bin/rc
exec /bin/exportfs -r /

I created 3 windows, each mounting a composite file system exp= orted from the previous one (by advancing the port numbers and srv names I = used above). And sure enough, the error message strings get longer and long= er!

Eventually I got= :
term% echo >/lib
/fd/0:10: > can= 9;t create: lib: is a directory: './power/lib': './power/power/= lib': './power/power/power/lib': 'lib'
=

I had to generate an 'is a directory&= #39; error to see this, rather than a 'file not found' error, as th= e latter seems to get treated a bit differently, and doesn't show this = concatenative effect.

This seems a bit daf= t.
I was thinking that maybe exportfs should be stripping o= ff the filename decoration after all: I'm not sure I can think of a sce= nario where sending it through Rerror is helpful.

but this still doesn't feel right.

exportfs is having to remove a decoration on an error string that the= kernel added for the benefit of the user. I think the kernel should probab= ly not be doing this. The outcome is nice, but maybe it would be better if = it were done in libc, perhaps in the implementation of %r. Maybe the system= call functions in user space could record the pathname in a global buffer = when an error occurs, and %r could use that.
Exportfs coul= d then forward the error string without the kernel decorating it, and we co= uld leave Linux v9fs alone.
Would that be better?


Although English is my first langu= age, I live among people for whom it mostly isn't, so I see these issue= s every day. There's definitely a tension between the obvious practical= ity of using English as a "Lingua Franca" and not wanting to lose= other languages, which is important to some people. The whole internationa= lisation thing is complicated and political, and thus hopefully something w= e can ignore here most of the time! I probably shouldn't have mentioned= it.  :D

= --17086903381.aee3ce.976941--