It would be hard to overstate how much work it took to make this 4-line commit possible https://git.lukeshu.com/sbc-harness/commit/?id=8cc87f8c1f25c9d3fec00561237891650a91b47a
Lots of things out there say that Styx was "a variant of the 9P protocol", but I haven't found anything that says what was actually different about it.
- The `typ` values that specify the message type are different (9P1 values start counting at 50, Styx starts counting at 0)
- Tcwalk/Rcwalk have been removed
- There is no authentication (so Tsession/Rsession have been removed, and Tattach/Rattach have been shortened)
There you go.
To anyone who knows Plan9/9p, am I reading this correct that 9p does not support extended attributes?
In the long-run, the easiest way to run #Plan9 1e (esp on non-PC platforms) will probably be to write a simple #GNULinux server program that serves BOOTP (pre-DHCP!) + TFTP for PXE boot, and #9P of the archive tarball. But 1e uses a much too old dialect of 9P for any existing software except for 1e itself to be able to serve it. And I don't want to try to write a server for it if I don't have a client to test with.
So getting `/sys/lib/pcdisk` to boot from FreeDOS is in the bootstrapping path.
I run a small #plan9 grid at home. This is my drawterm on my Linux PC connected to a Pi4 as a CPU server. It is viewing documents from my local PC, and I connected to a faster CPU in a window to play one of the NES games I wrote.
Is it theoretically possible to boot #Windows with a #9P root without having to create a disk image, similar to how it works on Linux? The only thing I found is #ninefs, which is very old and unmaintained and it's unclear if that's just an SMB replacement.
Motivation is explained here: https://wiki.qemu.org/Documentation/9p_root_fs
ninefs: https://code.google.com/archive/p/ninefs/
I'm not super familiar with Windows internals, so I'm not sure if this is possible with a driver or if it requires a custom kernel.
cc: #virtualization #qemu #virtio
In the #9P protocol, "T" messages are client→server requests, and "R" messages are server→client responses. Message types come in pairs of T and R variants (for example: "Topen" and "Ropen"). While there is a number assigned for T "error" requests, it is never used; only the R "error" response is used.
I do not know what they intended "T" and "R" to stand for.
But I'm half-convinced that "T" doesn't stand for anything and it just made them giggle whenever they got to write "Terror is illegal".
I can't be the only one who uses `[65, 66, 66, 65]` as testing bytes whenever you need something to stand out when doing low-level protocol work?
Once I feel that I am compliant (not many calls to implement) I will then get a Plan9/9front machine setup in (what I hope to be) my new lab (in the garage, like a true chad).
(Gangsta Glenda courtesy of: https://fqa.9front.org/fqa1.html#1.1.1)
Currently, for now, I am testing by letting v9fs (the 9p driver in the Linux kernel), generate the traffic that I need to decode. This is useful because once I get the Tattach/Rattach done then I should be able to get to the more common I/O operations.
As part of my introduction to Plan 9 I decided the best way to start in a more comfortable environment would be to implement a 9P protocol decoder (with a state machine), encoder and then a high-level client/server framework.
At work (zoo.dev) we use a lot of rust and specifically tokio for our servers -- I've been spending some time trying to develop style with it. I figured i'd be good chance to finish a *DECADE OLD* hack I wanted to implement. It's been a few weeks of nights/weekends hacking on it, and I just wrote it up after getting my old blog back online at https://notes.pault.ag/debugfs/
Cursed projects number... who's counting?
I adore Plan 9 (this shouldn't shock anyone). I figured I'd implement 9p in tokio to continue to hone my style and library knowledge.
I'll push my crate live soon (not yet since I've got some hard API breaks planned), but to test, I did some cursed shit:
Creating a symlink that begins with http:// will create a file that will do HTTP Range reads of the remote over 9p; was exceptionally fun to write. Also cursed.
A friend posted a link to this article. It seems a young'un has discovered #Plan9 and sees its distributed design as the future of operating systems.
I ran a #9p grid in the 1990s doing distributed computing research, and ran #Plan9, Amoeba, Sprite; so many utopian operating systems. They all were wonderful, and they all are very lonely. It really hurts seeing good ideas completely ignored for something good enough, but I hold out hope that some young buck will rediscover all these ideas, and pretend to have invented them. It really is the best case scenario. https://hackernoon.com/the-world-is-ready-for-a-new-type-of-operating-system