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
