9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Alyssa M via 9fans" <9fans@9fans.net>
To: 9fans <9fans@9fans.net>
Subject: Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
Date: Fri, 23 Feb 2024 07:12:18 -0500	[thread overview]
Message-ID: <17086903380.CDcDB65.976941@composer.9fans.topicbox.com> (raw)
In-Reply-To: <4f3c46d8-d10e-4bf4-a6f8-376ee11bb0c0@posixcafe.org>

[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]

(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:
As I understand it, the kernel is getting an error string from some file server, 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 mounts it.

But, another machine that mounts that exported file system will then decorate 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  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:
exec /bin/exportfs -r /

I created 3 windows, each mounting a composite file system exported 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 longer!

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

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

This seems a bit daft.
I was thinking that maybe exportfs should be stripping off the filename decoration after all: I'm not sure I can think of a scenario 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 probably 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 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 mostly isn't, so I see these issues every day. There's definitely a tension between the obvious practicality of using English as a "Lingua Franca" and not wanting to lose other languages, which is important to some people. The whole internationalisation thing is complicated and political, and thus hopefully something we can ignore here most of the time! I probably shouldn't have mentioned it.  :D 

9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M000b059a9ae286c6ee128aea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 4549 bytes --]

  reply	other threads:[~2024-02-23 12:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-04 15:07 [9fans] " Alyssa M via 9fans
2024-02-04 16:41 ` [9fans] " moody
2024-02-04 16:50   ` Alyssa M via 9fans
2024-02-04 22:19     ` Alyssa M via 9fans
2024-02-22 19:45       ` Alyssa M via 9fans
2024-02-22 20:27         ` Jacob Moody
2024-02-23 12:12           ` Alyssa M via 9fans [this message]
2024-02-23 18:18             ` Jacob Moody
2024-02-25  1:01               ` Alyssa M via 9fans
2024-02-23  8:03         ` Lucio De Re
2024-02-04 16:46 ` moody

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17086903380.CDcDB65.976941@composer.9fans.topicbox.com \
    --to=9fans@9fans.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).