docs: Add apple/container integration analysis#211
docs: Add apple/container integration analysis#211cgwalters wants to merge 1 commit intobootc-dev:mainfrom
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds extensive documentation, including a detailed analysis of a potential integration between bcvk and Apple's container tool. The changes introduce three new documentation pages comparing bcvk with bootc, podman-bootc, and analyzing the apple/container integration. The new analysis in vs-apple-container.md is thorough, covering technical implementation details and providing a clear path forward. The documentation is well-structured and valuable. I have one minor suggestion to correct a version number for accuracy. It would also be beneficial to update the pull request title and description to reflect the full scope of the documentation added.
Describe how bcvk could reuse ext4 filesystem images that apple/container already creates, rather than reimplementing ext4 synthesis. The key insight is that apple/container's snapshot store contains plain ext4 files at predictable paths, and bcvk can read them directly. Cover the kernel extraction problem: bcvk always boots the image's own kernel, so it needs to read the kernel out of the ext4 image before booting. The ext4-view crate (pure Rust, read-only ext4 access) solves this without requiring mount privileges. Also document apple/container's storage APIs (content store layout, snapshot store structure) based on source analysis of the Containerization Swift package. Assisted-by: OpenCode (claude-opus-4-6) Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
force-pushed
the
vs-apple-container
branch
from
c753572 to
8269355
Compare
|
Thanks for putting it together but the document is long and difficult to read. Lots of repeated information, minor details given too much attention, paragraphs don't seem to flow towards an overall point |
|
Thank you, you're 100% right. This was a LLM-assisted (but definitely guided and partially checked) research dump, intended to be early raw material for further refinement. I recently read https://rfd.shared.oxide.computer/rfd/0576 and agree with a lot of it, though I have specifically found this "LLMs for writing" to generate rough draft research reports to actually be really useful sometimes, but for sure it should be clearly marked as such and not presented to humans by default. A procedure I'm starting to follow is filing an issue, and then editing the issue with a |
2 participants
Describe how bcvk could reuse ext4 filesystem images that apple/container already creates, rather than reimplementing ext4 synthesis. The key insight is that apple/container's snapshot store contains plain ext4 files at predictable paths, and bcvk can read them directly.
Cover the kernel extraction problem: bcvk always boots the image's own kernel, so it needs to read the kernel out of the ext4 image before booting. The ext4-view crate (pure Rust, read-only ext4 access) solves this without requiring mount privileges.
Also document apple/container's storage APIs (content store layout, snapshot store structure) based on source analysis of the Containerization Swift package.
Assisted-by: OpenCode (claude-opus-4-6)