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
I'm no expert, but I use a British keyboard on my RPi, so I have encountered
the need to change the key map.
I would expect that the 'de' key map file will be designed for this keyboard
layout: https://en.wikipedia.org/wiki/QWERTZ#Austria_and_Germany
Perhaps check whether your keyboard looks
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
> 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:
Is the presence of the duplicate names when reading a union directory actually
needed/used anywhere? Or is it just an artefact of the most straightforward
implementation for Plan 9?
I ask because I'm implementing the Plan 9 system calls on my own OS. If I don't
have to implement the name
Thanks!
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tf4c3dc658874afea-M36739d26a8ea4c9534babbdc
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Well I got curious, and wrote a test program for my Linux RPi:
Doing the equivalent of what du(1) does (a recursive tree walk statting every
file) seemed to be about 15% faster with openat/fstatat than with open/lstat.
This was on a local drive (SD card).
Over 9p to my Plan 9 RPi from Linux it
I left the oven on for my partly-baked idea.
I'm now thinking that with fd 5 as an example:
open ("#d/5dir/a/b/c", ...)
might be a practical way to do this (the syntax I suggested earlier would
require walking from a file, which wouldn't be sensible).
So I went snorkeling in the kernel to see
Oooh! More pixels!
This is wonderful, thank you!
I had the same situation, but I didn't know this was possible.
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T42a55b55ffb81417-M02cd60501c363e99ed9163bd
Delivery options:
Are you thinking narrowly about "What changes to the Plan 9 kernel would you
make to emulate the Linux openat() system call" or more generally about "How
would you design a facility for plan 9 that provides an equivalent service?
As I understand it from the rationale section on the linux man
Moody wrote:
"What you _would_ want for this would be the ability to walk from the existing
fd, however the limits of 9p walk make this a bit impossible to implement in a
great way in my opinion. "
Maybe the chan could keep two fids: the original walked fid, and an opened
clone of that fid?
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
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
(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
14 matches
Mail list logo
