https://github.com/rvs/planD Skip to content Toggle navigation Sign up * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Case Studies + Customer Stories + Resources * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing [ ] * # In this repository All GitHub | Jump to | * No suggested jump to results * # In this repository All GitHub | Jump to | * # In this user All GitHub | Jump to | * # In this repository All GitHub | Jump to | Sign in Sign up {{ message }} rvs / planD Public * Notifications * Fork 0 * Star 28 Plan9 from Containerspace License Apache-2.0 license 28 stars 0 forks Star Notifications * Code * Issues 0 * Pull requests 0 * Actions * Projects 0 * Security * Insights More * Code * Issues * Pull requests * Actions * Projects * Security * Insights rvs/planD This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. master Switch branches/tags [ ] Branches Tags Could not load branches Nothing to show {{ refName }} default View all branches Could not load tags Nothing to show {{ refName }} default View all tags Name already in use A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch? Cancel Create 1 branch 0 tags Code * Local * Codespaces * Clone HTTPS GitHub CLI [https://github.com/r] Use Git or checkout with SVN using the web URL. [gh repo clone rvs/pl] Work fast with our official CLI. Learn more. * Open with GitHub Desktop * Download ZIP Sign In Required Please sign in to use Codespaces. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching GitHub Desktop If nothing happens, download GitHub Desktop and try again. Launching Xcode If nothing happens, download Xcode and try again. Launching Visual Studio Code Your codespace will open once ready. There was a problem preparing your codespace, please try again. Latest commit @rvs rvs Initial version of Plan9D ... 39ebac1 May 25, 2020 Initial version of Plan9D Signed-off-by: Roman Shaposhnik 39ebac1 Git stats * 2 commits Files Permalink Failed to load latest commit information. Type Name Latest commit message Commit time 9front-amd64 9front-arm64 9front 9vx authsrv9 base drawterm go-p9p go plan9port scripts u9fs LICENSE Makefile README.md docker-compose.yml View code planD: Plan9 from Containerspace Plan9 on "cloud native" infrastructure 1. VM API References XXXX TODO README.md planD: Plan9 from Containerspace Looking back at it from 2020 it clearly seems that the Original Plan9 was very much ahead of its time. Some of its insigts are much better appreciated 30 years later when the general "zeitgeist" of the software developer community has enthusiastically moved towards fully distributed, eventually consistent systems. These types of software systems may feel new, but a lot of the ideas behind them were first articulated and implemented in Plan9. One of these fundamental ideas was the notion of a system composed of microservices communicating via a well established system of network API requests encoded as 9P messages. Of course, these days, we would express a system like this through use of containarized applications communicating via REST or gRPC. Some even suggest that these new patterns will be as influential in software design as object oriented patterns have been. While the jury is still very much out on that bombastic claim (and arguably the Gang of Four book has done more damanage than good to teh software industry) one fact is undeniable: OCI contatiners have very much become the building blocks of moderm distributed systems. Container technology like Docker, however, is great at helping you package your application inside of the container, but it doesn't really help in figuring out what is that you are packaging. There are multiple attempts of retrofiting old school Unix/Linux development tools to this new cotnainerized world. Arguably, the rise of Alpine Linux as a basis for how UNIX applications need to be containerized is a direct result of trying to answer this question: what are the best building blocks to go inside containers This project attempts at giving an answer to the same question that is rooted in Plan9, rather than UNIX software development culture. After all, what was Plan9 if not an attempt to fix all the cruft that accumulated in UNIX over the years! One final note before we deep dive into containerizing Plan9. A lot what you will read here is condensed presentation of the following 5 resources. Each of them is absolutely amazing in its own right and contains treasure troves of collective Plan9 wisdom: * Plan 9 from Bell Labs * cat-v.org * Plan 9 Wiki * 9front.org * plan 9 on openbsd If you want to help with this project, please take a look at the # TODO list at the bottom. Plan9 on "cloud native" infrastructure Plan9 was concieved in an infrastructure landscape that was massively heterogenous hardware and (worse yet!) networking perspectives. Today's "cloud native" infrastructure is mostly amd64 and arm64 compute devices connected by TCP/IP networks. On the compute side, you can consume that infrastrucure by leveraging one of the two runtime APIs: 1. a generalized Virtual Machine API 2. a POSIX-like process group API (typically backed by a Linux kernel) 1. VM API VM APIs are the closes to the original view that Plan9 had of hardware infrastructure. In fact, the job of a Plan9 kernel can be greatly simplified today since there's absolutely no need to support the vast collection of various I/O devices: a very basic set of disk, network and serial devices emulated by the VMM would suffice (it will be nice, however, to support virtio in Plan9: see our #TODO list). In fact, the boostrapping phases of the Plan9 kernel and how they interplay is extremely congenial with the "cloud native" infrastructure views of today: 0. Plan9 has an ability of producing a self-contained multiboot kernel binary from its build. On some systems this kernel binary can be used directly, on other ones it needs to be wrapped into a trivial disk image. 1. As a matter of fact, the self-contained nature of the Plan9 kernel image extends beyound just the binary bits that get loaded into kernel memory. Plan9 as an ability of also packaging filesystem content of the initial root filesystem right into the kernel binary itself (thus obviating the need for things like initrd in Linux). The content of this filesystem is managed by the root device and what files get included in the binary kernel image gets managed by bootdir section of the architecture specific (the example above is for x86 architecture) Plan9 kernel build script (exploring various of those scripts in the same folder will give you a taste of how to build different flavors of Plan9 kernel). 2. One of the files that gets included in that root device filesystem is /boot/boot. This executable is the first one to run and its job is to connect to the actual filesystem. As its last step, /boot/boot executes /$cputype/init [options] and at that point the Plan9 system is considered to be fully bootstrapped. It must be kept in mind, that init is sensitive to what "flavor" of the Plan9 this is. You should just read the source above, but the key takeaway is that depending on the flavor you can expect /rc/ bin/cpurc, /rc/bin/termrc and lib/profile hooks to be called before init transitions into effectively a shell /bin/rc console. Most of the time Plan9 is pretty stateless so you can simply kill a VM without any kind of shutdown sequence. However, if your instance is managing disk (and thus state) you may need to call fshalt -r which, provided that you booted with acpi=1 in plan9.ini will also call scram(8). Plan9 kernel booting can be further customized by using an intermediate boot kernel (yes! Plan9 effectively supported kexec way before Linux kids dreamt it up) passing a series of command line arguments to the final Plan9 kernel via plan9.ini. This kind of boot sequence is described in 9boot and is mostly helpful if you decide to do PXE booting. References * Plan9 legacy * Plan9 9k XXXX how differnt things (networks, disk, bitmap) get represented in plan9 via devices (/dev/sdC0) and userspace (partfs) TODO * Provide a containerized (possbily based on linuxkit) build of a Plan9 kernel * Explore linuxkit's ability to load various images into public clouds as VMs * Explore running on Plan9 kernel on firecracker VMM * Implement key virtio devices in Plan9 kernel * Explore cloudboot for PXE booting Plan9 About Plan9 from Containerspace Resources Readme License Apache-2.0 license Stars 28 stars Watchers 3 watching Forks 0 forks Report repository Releases No releases published Packages 0 No packages published Languages * C 88.7% * Dockerfile 7.9% * Shell 1.7% * Makefile 1.7% Footer (c) 2023 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact GitHub * Pricing * API * Training * Blog * About You can't perform that action at this time. You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.