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-ob21.topicbox.com (tb-ob21.topicbox.com [173.228.157.67]) by inbox.vuxu.org (Postfix) with ESMTP id F03EE237F2 for ; Sun, 4 Feb 2024 16:08:02 +0100 (CET) Received: from tb-mx0.topicbox.com (tb-mx0.nyi.icgroup.com [10.90.30.73]) by tb-ob21.topicbox.com (Postfix) with ESMTP id E002337E46 for ; Sun, 4 Feb 2024 10:07:59 -0500 (EST) (envelope-from bounce.mM2d8b0b7bbb2f59b0acb40d34.r522be890-2105-11eb-b15e-8d699134e1fa@9fans.bounce.topicbox.com) Received: by tb-mx0.topicbox.com (Postfix, from userid 1132) id 91521C4ABA9; Sun, 4 Feb 2024 10:07:59 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=9fans.net; h=to :message-id:date:mime-version:content-type :content-transfer-encoding:list-help:list-id:list-post :list-subscribe:reply-to:subject:from:list-unsubscribe; s= dkim-1; t=1707059279; x=1707145679; bh=FOgTeYzn7L1SWoEjp2jwpbLlW yyzoXrBrTdfOy1W9WE=; b=STJhm0PElEZnaSZIYc54BDSwbhVzc/IDzfP10C9+7 tJkaLWebL/27EGkjATY9E3bBkUv2PopP/kJ2acCkG202tvM8bj2l/IMzEk1UsahM sSjsJCwbJGNDaYVgr+bsEMuy+CvsmEJ5VFvhThHNWwD8rnYCnogAoeUi7sAcvF+G zE= To: 9fans <9fans@9fans.net> Message-Id: <17070592670.E7CF6327b.7700@composer.9fans.topicbox.com> Date: Sun, 4 Feb 2024 10:07:47 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=17070592671.566d.7700 Content-Transfer-Encoding: 7bit Topicbox-Policy-Reasoning: allow: sender is a member Topicbox-Message-UUID: 2801502c-c36f-11ee-935d-34f640decc0b Archived-At: =?UTF-8?B?PGh0dHBzOi8vOWZhbnMudG9waWNib3guY29tL2dyb3Vwcy85?= =?UTF-8?B?ZmFucy9UYmM3OGQyOWFiMDQ2NTJhMi1NMmQ4YjBiN2JiYjJmNTliMGFjYjQw?= =?UTF-8?B?ZDM0Pg==?= List-Help: List-Id: "9fans" <9fans.9fans.net> List-Post: List-Software: Topicbox v0 List-Subscribe: Precedence: list Reply-To: 9fans <9fans@9fans.net> Subject: [9fans] Hello, RPi fixes and bind -b trouble 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:M2d8b0b7bbb2f59b0acb40d34:1:LM2a50-QO7v3lc3v_WJRvKfnVDsl0OGFEh5Ky_2lBbw --17070592671.566d.7700 Date: Sun, 4 Feb 2024 10:07:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 us= ed Plan 9 itself until now... So far I've patched my installation in a couple of small ways, which has be= en a useful exercise to get started with: I think the v6fs support in tapefs has a bug: the last line of doread() sho= uld be return buf+off; rather than return buf; This only shows up if your reads are unaligned with block boundaries. I thi= nk 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 su= pposedly not leak through into Linux user space, but does... It seems there's a mismatch between the error strings that the plan 9 kerne= l 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 n= ot 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 wind= ow system (not the catclock - that one gives me the creeps!). I also have b= itmaps 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-M2d8b0= b7bbb2f59b0acb40d34 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription --17070592671.566d.7700 Date: Sun, 4 Feb 2024 10:07:47 -0500 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Plan9People!

I finally stumbled across Richard Miller's Raspberry Pi image a w= hile 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:
<= /div>

I think the v6fs support in tapefs has a bug: th= e last line of doread() should be
return buf+off;
rather than
return buf;
This only sh= ows up if your reads are unaligned with block boundaries. I think v32fs.c h= as the same bug, but it's okay in v10fs.c.
I realise th= e 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 prett= y much not working for me (???!): I got error 526 which is ESERVERFAULT - u= ntranslatable error, which should supposedly not leak through into Linux us= er space, but does...
It seems there's a mismatch betwe= en 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 apparent= ly currently expects:
file does not exist
o= r
file not found
in github/torvalds/linux/n= et/9p/error.c:p9_errstr2errno()
What I have replaces the &#= 39;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 Debi= an 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 v9= fs. 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 give= s me the creeps!). I also have bitmaps and text beginning to work, but ther= e'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 i= t 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 i= t when I ls /dev! Very odd.
This is not actually blocking m= e at the moment, but if anyone has any clues about what I might be doing wr= ong it would save me a lot of hair-pulling?

9fans / 9fans / see discussions + participants + delivery&n= bsp;options Permalink
= --17070592671.566d.7700--