Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
On 2/22/24, Alyssa M via 9fans <9fans@9fans.net> wrote: > [ ... ] > Perhaps I'm missing something obvious. > You're not: there is a very large grey area between English language exceptionalism and internationalisation madness. As a citizen in a country where eleven languages are declared equivalently "official" with sign language on the way to be added to the list, I can offer some opinions. First, I see small groups of tourists in the backpackers I co-manage being quite comfortable using English across the various European languages that are their mother tongues and secondly, the local vernaculars (nine African languages and Afrikaans which derives from Dutch) are absorbing more and more English, quite noticeably so, but the local variety of English is also being distorted to accommodate the local phonetics (that, of course happens across the Anglophone world and even in countries where English is an acquired taste), Catering for internationalisation is a losing game, adjusting for it is a short term waste of effort, with no clear vision of what rules could possibly improve the situation. I guess being English speaking is an asset and that may well become the foundation. Occasionally Esperanto is mentioned, but my experience suggests that is as hopeless as the adoption of Swahili in Africa. PS: thanks for documenting your efforts, they will save others a lot of brain-ache. -- Lucio De Re 2 Piet Retief St Kestell (Eastern Free State) 9860 South Africa Ph.: +27 58 653 1433 Cell: +27 83 251 5824 -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-Mda9d66a0e626be4b46745244 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
(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: #!/bin/rc 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
Re: [9fans] Re: Hello, RPi fixes and bind -b trouble
Responses in-line. On 2/23/24 06:12, Alyssa M via 9fans wrote: > (Lucio posted while I've been thinking/composing/trying things...) > > Thanks for putting up with me! No, thank you for your thoughts and helping test. > > 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: > #!/bin/rc > 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' Oh dear yes that does seem to be a bit of an issue. > > 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. I am curious as to why this was treated differently, can't recall off the top of my head. > > 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? Maybe? It's hard to tell without looking at a patch that does this. It seems like the end result would be the same. Exportfs is chucking the resulting errstr across the network. So whether set by libc or the kernel doesn't make much of a difference. I am also not entirely sure that having an extra "opt-in" step is the correct thing to do here. If there were to be a way around these problems then perhaps it would be worth pursuing. > > > 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 Yes that is a tough question. I have spent a lot of time thinking about language support on 9front. What I would like first before "localization" of things like error messages is just to be able to input and display the multitude of languages that people use. Right now we are not so great about this. Some of the work I've done for 9front has helped improve this, we have more aware unicode routines with respect to word breaks, line breaks, and grapheme breaks. Ktrans has been included and expanded to cover some chinese input methods. However the system still has issues dealing with decomposed unicode, both in display and input. There are lots of tricky things to get right there w.r.t. mouse selection, display and so on that this current code was just not built for. Part of that problem is the bitmap fonts are just not built for this world really either. I find these to be much more pressing and interesting challenges. Thanks, moody -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M2affd026483c5a273ee22a92 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] Re: Mounting a 9P filesystem under a Linux "user namespace"
Again for the record, if anybody is looking for a 9P2000.L FUSE implementation, I had to write one, I used github.com/hugelgupf/p9 as a base: git clone g...@the-dam.org:f29p With that, one can mount a 9P2000.L server from inside a linux 'mount namespace'. I'll talk about that if my paper passes the IWP9 review. Cheers, Edouard. Edouard Klein writes: > For the record here is the lkml post > https://lkml.org/lkml/2023/10/28/155 > Edouard Klein writes: > >> Thanks Moody for the nudge in a direction I hadn't explored. >> >> It seems that Linux does not see 9p as been safe to mount without >> privilege. From what I understand, only FS with the FS_USERNS_MOUNT flag >> can be mounted in a user namespace. It seems that v9fs is not one of >> them: >> >> For example, tmpfs is a safe FS, and I can do: >> unshare --user --map-root-user --mount >> mount -t tmpfs tmpfs mnt/mnt1/ >> >> and it works. >> >> However, if I do: >> unshare --user --map-root-user --mount >> mount -t 9p -o trans=unix /run/9p/srv4 mnt/mnt1 >> >> I get mount: /home/edouard/mnt/mnt1: permission denied. >> >> >> I've sent an email to the linux kernel mailing list to see if somebody >> there has any up to date information. >> >> Somebody tried the same thing in 2018: >> https://lore.kernel.org/all/39b08c53-3449-3164-c1b1-44ac587dd...@metux.net/T/ >> Seemingly without succeeding. >> >> The end of the above thread is a bit worrying: >>> plan9fs would >>> also be a candidate for that kind of treatment if it had a maintainer. >> >> I did not know v9fs was unmaintained, I find that a bit surprising. It >> does work very reliably. >> >> I'll keep this list updated as I make progress. >> >> Cheers, >> >> Edouard >> >> mo...@posixcafe.org writes: >> >>> Edouard, >>> >>> I am no Linux expert, but I think if you create a mount namespace as part of >>> the user namespace you will be allowed to execute mounts without root. In >>> terms of clients, I am not aware >>> of any other then the one within the linux kernel. >>> >>> Regards, >>> Moody >>> 9fans / 9fans / see discussions + participants + delivery options Permalink -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tb5d039f675c54046-M9d4a22b7f8e14bfa2bb23e3c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
