[9fans] Hello, RPi fixes and bind -b trouble

[9fans] Hello, RPi fixes and bind -b trouble

[Alyssa M via 9fans]

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

Hello Plan9People!

I finally stumbled across Richard Miller's Raspberry Pi image a while back and managed to install it on an RPi, and have been learning more about it. I've used the 9P protocol for a couple of projects, but haven't actually used Plan 9 itself until now...


So far I've patched my installation in a couple of small ways, which has been a useful exercise to get started with:

I think the v6fs support in tapefs has a bug: the last line of doread() should be
return buf+off;
rather than
return buf;
This only shows up if your reads are unaligned with block boundaries. I think v32fs.c has the same bug, but it's okay in v10fs.c.
I realise the number of people who care about this may be very small. :)


I also made a fix to exportfs.c:reply() so it works with the Linux v9fs on my other RPi, which was otherwise pretty much not working for me (???!): I got error 526 which is ESERVERFAULT - untranslatable error, which should supposedly not leak through into Linux user space, but does...
It seems there's a mismatch between the error strings that the plan 9 kernel produces and the ones that v9fs knows how to deal with, as exportfs just passes them along:
Plan 9 produces:
'foo' does not exist
in /sys/src/9/port/chan.c:namelenerror()
v9fs apparently currently expects:
file does not exist
or
file not found
in github/torvalds/linux/net/9p/error.c:p9_errstr2errno()
What I have replaces the 'nice' error string with what v9fs expects. It's not a great fix, but I'm not sure what (or where?) the fix *should* be??
I see the same problem between Ubuntu and 9front as I do between RPi Debian and Rpi Plan 9, so this seems to be a general problem. Without this fix, I couldn't actually create a file on a Plan 9 export from Linux via v9fs. It's not just a weird error message.


Currently I'm trying to build a 'drawterm' server for my experimental OS - so far I can run the clock program on Plan 9 and have it display on my window system (not the catclock - that one gives me the creeps!). I also have bitmaps and text beginning to work, but there's not enough there to run sam or rio yet.

I'm having trouble with bind-mounting my 9p server on Plan 9's /dev, though: the old /dev files are all there, but when I bind -b over it from /n only the files in the directory I'm binding show up in ls! It's like the -b is being ignored by bind(1), but if I ls /dev/null (for example) it's actually there - but after the bind I can no longer see it when I ls /dev! Very odd.
This is not actually blocking me at the moment, but if anyone has any clues about what I might be doing wrong it would save me a lot of hair-pulling?

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

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

[9fans] Re: Hello, RPi fixes and bind -b trouble

[moody]

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

The issue with exportfs and linux v9fs has been fixed in 9front commit 6eed7a47863553bab31c7f9b1b5b314989efc640. It is regrettable that we had to shift around the err string to make linux happy, but I have no interest in getting involved with changing it on the linux side.

That issue with bind seems to me to be a bug in your walk code, the way the devmnt stuff works is that it walks down the union list and stops when a server returns that a file exists via walk. Like what you have is a server that is returning "yes I have this file" via walk, but when actually reading the directory, it does not show it. Just my guess anyway.

I plan to look in to that tapefs bug. 9front hasn't touched this code and I agree something seems fishy. Thank you for debugging this, I'll test it out and commit a fix.


Thanks,
moody

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

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

[9fans] Re: Hello, RPi fixes and bind -b trouble

[moody]

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

Err sorry, I realize now my diagnoses of what devmnt is doing is likely not entirely correct, but I would bet money on this being a bug in your walk code.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-Mf5a02677fb44b38cc6da70ff
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[9fans] Re: Hello, RPi fixes and bind -b trouble

[Alyssa M via 9fans]

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

> On Sunday, 4 February 2024, at 4:46 PM, moody wrote:
>> I would bet money on this being a bug in your walk code.
That seems entirely possible! Thanks for the pointer.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M36646a9bf5752d3ed7b0863f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[9fans] Re: Hello, RPi fixes and bind -b trouble

[Alyssa M via 9fans]

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

Mystery solved: the bug was in my Ropen code. I was not returning QTDIR in the qid.type when opening the directory.
I'd hazard a guess that because Rwalk said it was a directory, but then Ropen said it was a file, sysfile.c:read() in the Plan 9 kernel didn't call unionread(), so only the first directory in the union mount was read. Maybe??
Anyway it works now. :)
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M4b5259ac6e9ab466572bbbf3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[9fans] Re: Hello, RPi fixes and bind -b trouble

[Alyssa M via 9fans]

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

Well, my daughter has kindly given me a couple of her spare raspberry pis - a pi4 and a pi5.
I've put 9front on the pi4, and have been having a look at it. I had to use the Raspberry Pi Imager program this time. windd didn't work (she thinks this might be a feature of the later Pis). There are 5 computers on my desk now! :) I'm running out of room for my teacup. I have a 2-port kvm, and I could be using drawterm for the Plan 9 installations, but if I do that I won't be motivated to finish implementing a drawterm for my own system...

I tried mounting a 9front exportfs on Linux, but encountered the same problem I mentioned earlier: the error strings don't match what v9fs on Linux is expecting, with effect that I can't create files from Linux on a file system exported from 9front either. I think the problem is that v9fs tries to open a file before creating it: if it doesn't get an error that it can recognise as corresponding to ENOENT it won't attempt the subsequent create message.
v9fs currently does an exact match on the error string returned in Rerror and will recognise any of the following strings:

"No such file or directory"
"directory entry not found"
"file does not exist"
"file not found"
"illegal path element"
"directory entry is not allocated"

as being different ways of saying ENOENT (which has the numeric value of 2). It looks like the 4th Edition kernel prefixes these with the filename in quotes, e.g.:

"'foo' file does not exist"

I spoke earlier about my patch to exportfs(4) to get around this. 
On 9front, though, I'm seeing:

"not found: 'foo'"

or

"file does not exist: 'foo'"

depending on which file system is involved. Even if I apply my exportfs patch to 9front, it looks like hjfs(1) has introduced "not found" as a  new way to say "file does not exist", and v9fs is not going to understand that either... I suppose I could add a special case in exportfs to translate that into "file not found".

I see several problems: 
The first and most obvious one is that v9fs doesn't cope well with the variety of ways ENOENT gets encoded over 9p. The second is that there seems to be an assumption that:
a) errors are only ever immediately reported to the user, and
b) the user speaks English...

For me, I have a very analogous problem with the 9p client file system adapter on my own OS:
I'm thinking at this point that I'm going to have to extract the currently fixed strings it recognises into a file (which I can edit to keep up with the times) and also use regular expressions so that the entries in that file can actually pattern-match any embedded quoted filename, allowing for future creativity in the ways it can get inserted into the error string returned via Rerror...
I'm not sure I quite believe I'm seriously contemplating doing this.

Perhaps I'm missing something obvious.

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

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

Re: [9fans] Re: Hello, RPi fixes and bind -b trouble

[Jacob Moody]

I apologize I had recalled incorrectly in my previous email on this topic.
We had intentions of fixing this issue with v9fs but only half of the work
was done. 9front changed that specific error in the kernel to suffix the
filename instead of prefix the filename to

A) be more consistent with userspace
B) allow use of strncmp() with the error

The intention was to submit a patch to Linux to change their memcmp()
to use strncmp() to allow this to be recognized. If I recall mcf had
intended to submit said patch but I am unaware of where that went.

In the meantime a hack around in exportfs is probably the best option.

In regards to hjfs, I agree it should probably be brought in line with
this if this is the convention we would like v9fs to use. I will purpose
a patch to change it on the 9front list.


Apologies and thank you,
moody

On 2/22/24 13:45, Alyssa M via 9fans wrote:
> Well, my daughter has kindly given me a couple of her spare raspberry pis - a pi4 and a pi5.
> I've put 9front on the pi4, and have been having a look at it. I had to use the Raspberry Pi Imager program this time. windd didn't work (she thinks this might be a feature of the later Pis). There are 5 computers on my desk now! :) I'm running out of room for my teacup. I have a 2-port kvm, and I could be using drawterm for the Plan 9 installations, but if I do that I won't be motivated to finish implementing a drawterm for my own system...
> 
> I tried mounting a 9front exportfs on Linux, but encountered the same problem I mentioned earlier: the error strings don't match what v9fs on Linux is expecting, with effect that I can't create files from Linux on a file system exported from 9front either. I think the problem is that v9fs tries to open a file before creating it: if it doesn't get an error that it can recognise as corresponding to ENOENT it won't attempt the subsequent create message.
> v9fs currently does an exact match on the error string returned in Rerror and will recognise any of the following strings:
> 
> "No such file or directory"
> "directory entry not found"
> "file does not exist"
> "file not found"
> "illegal path element"
> "directory entry is not allocated"
> 
> as being different ways of saying ENOENT (which has the numeric value of 2). It looks like the 4th Edition kernel prefixes these with the filename in quotes, e.g.:
> 
> "'foo' file does not exist"
> 
> I spoke earlier about my patch to exportfs(4) to get around this.
> On 9front, though, I'm seeing:
> 
> "not found: 'foo'"
> 
> or
> 
> "file does not exist: 'foo'"
> 
> depending on which file system is involved. Even if I apply my exportfs patch to 9front, it looks like hjfs(1) has introduced "not found" as a  new way to say "file does not exist", and v9fs is not going to understand that either... I suppose I could add a special case in exportfs to translate that into "file not found".
> 
> I see several problems:
> The first and most obvious one is that v9fs doesn't cope well with the variety of ways ENOENT gets encoded over 9p. The second is that there seems to be an assumption that:
> a) errors are only ever immediately reported to the user, and
> b) the user speaks English...
> 
> For me, I have a very analogous problem with the 9p client file system adapter on my own OS:
> I'm thinking at this point that I'm going to have to extract the currently fixed strings it recognises into a file (which I can edit to keep up with the times) and also use regular expressions so that the entries in that file can actually pattern-match any embedded quoted filename, allowing for future creativity in the ways it can get inserted into the error string returned via Rerror...
> I'm not sure I quite believe I'm seriously contemplating doing this.
> 
> Perhaps I'm missing something obvious.
> 
> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription> Permalink <https://9fans.topicbox.com/groups/9fans/Tbc78d29ab04652a2-M73bf1acd981988335f610ae6>

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

Re: [9fans] Re: Hello, RPi fixes and bind -b trouble

[Lucio De Re]

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

[Alyssa M via 9fans]

[-- 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:
#!/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

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

Re: [9fans] Re: Hello, RPi fixes and bind -b trouble

[Jacob Moody]

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: Hello, RPi fixes and bind -b trouble

[Alyssa M via 9fans]

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

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, and wrapped the open() call (as an 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 potentially a lot of places that would notice, and I haven't chased them all down.  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 decoration 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 earlier.

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

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