Fuchsia project has the concept of "products". A product defines the software configuration that a build will produce. Most critically, a product typically defines the kinds of user experiences that are provided for, such as what kind of graphical shell the user might observe, whether or not multimedia support is included, and so on. Zircon standalone is like a bare bone fuchsia product containing just the kernel and a framework for compiling userspace programs, along with some utility libraries.
Main advantages is build time. The smallest fuchsia product is "bringup" and it's 10-20 times bigger than the kernel. Building it takes around 30 minutes on a 4 core machine. Zircon Standalone might provice a more pleasant experience if you don't have brock lesnar of a pc.
It might also be useful if you're trying to run zircon on a resource constrained system. Zircon can boot with 8mb of ram, and it could be brought down some more by abandoning multiboot (it causes duplication of around 2mb of data), but that will require writing a custom bootloader.
Fuchsia permission model builds on top of zircon. It locks down some capabilities like process creation behind system services. Access to those services is managed by the component framework and capability routing. So a regular userspace process that isn't bootsvc (the init process of fuchsia) cannot use the full extent of zircon system calls. For fuchsia project, zircon is a means to an end, the end being the complete operating system. Zircon standalone focuses on zircon as an end in itself.
- Clone the repository.
Set the following environment variables:
ZIRCON_STANDALONE_DIR: Path to zircon_standalone repository
FUCHSIA_DIR: Fuchsia source root.
FUCHSIA_OUT: Fuchsia build output directory.
TARGET_IS_ARM: Whether you're compiling for ARM.
Execute this command in the fuchsia project directory:
fx ninja -C $FUCHSIA_OUT `cat $ZIRCON_STANDALONE_DIR/build/deps_x64.txt`It will compile the kernel and the bootloader:
make && ./build/run_x64.sh
Dependencies on Fuchsia project
The init process code depends on zircon headers in
//zircon/system/publicfor type definitions and preprocessor constants.
- The build process uses kernel executable and bootloader executable from the build output directory.
libs/headers/syscall_signatures.his generated from a file named cdecls.incthat is generated by the build system from fidl declarations. You only need to regenerate it if the syscall api changes. There's a makefile target for that.
Building on ARM host
I don't have an ARM workstation. PRs are welcome for adding support for ARM host. (Preferably as an environment