This PR introduces a wanix CLI that replaces the dev server and has a command equivalent to our bundle generation command. However, it works much differently. Instead of "bundle" where it assembled the bootloader.js and other files right there, the "loader" command will write files out from embedded data in the binary itself. "Bundling" is now just building the wanix CLI.
The new boot dir is embedded into the wanix CLI. It contains the bootdata files to bootstrap the wanix kernel, the loader.js, the HTML files needed for a deploy and is a staging directory for kernel.gz and initfs.gz. Both of those files are created by make.
This PR also breaks Wanix because it's incomplete. We still need to alter the kernel to start using the wanix-initfs.gz file if /sys/init does not exist, and place files from there. This is what's left of #138, which this PR implements a lot of.
One thing I didn't do is rename the existing initfs in the codebase to bootfs.
This PR introduces a wanix CLI that replaces the dev server and has a command equivalent to our bundle generation command. However, it works much differently. Instead of "bundle" where it assembled the bootloader.js and other files right there, the "loader" command will write files out from embedded data in the binary itself. "Bundling" is now just building the wanix CLI.
The new
boot
dir is embedded into the wanix CLI. It contains the bootdata files to bootstrap the wanix kernel, theloader.js
, the HTML files needed for a deploy and is a staging directory forkernel.gz
andinitfs.gz
. Both of those files are created by make.This PR also breaks Wanix because it's incomplete. We still need to alter the kernel to start using the
wanix-initfs.gz
file if/sys/init
does not exist, and place files from there. This is what's left of #138, which this PR implements a lot of.One thing I didn't do is rename the existing
initfs
in the codebase tobootfs
.