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
