Compare commits
4 Commits
b64d535824
...
450f2c7ef5
Author | SHA1 | Date | |
---|---|---|---|
450f2c7ef5 | |||
0026f0cb4c | |||
8817ba5772 | |||
9107cb1553 |
30
README.md
30
README.md
|
@ -13,13 +13,41 @@ aarch64. Install the following:
|
|||
* [Kraftkit](https://unikraft.org/docs/cli/install)
|
||||
|
||||
Then run `zig build run` and everything will compile and run. The zig source
|
||||
code is all in the `ziggy` directory
|
||||
code is all in the `ziggy` directory. This is all prototype level code at this
|
||||
point.
|
||||
|
||||
Reproducibility
|
||||
---------------
|
||||
|
||||
This build is not reproducible at the moment. The problem is that we need v0.17.0
|
||||
or higher (this may be an issue with QEMU installed version, so YMMV). Kraftfile
|
||||
is designed to pin to a specific version, but as of this writing, versions of
|
||||
unikraft core post 0.16.1 are not listed in https://manifests.kraftkit.sh/unikraft.yaml,
|
||||
and as a result cannot be used, so we are forced to use "stable" as the version.
|
||||
|
||||
undefined.c
|
||||
-----------
|
||||
|
||||
This file aims to fill in all the undefined symbols that are referenced when
|
||||
a zig project links libC (necessary for unikraft kernel development). However,
|
||||
this is very incomplete. The `.config.hellowworld_qemu-x86_64` file, usually
|
||||
managed by the invocation of the TUI started by `kraft menu`, will add/remove
|
||||
features that result in various libc symbols being implemented. A few
|
||||
`#ifdef` statements exist currently, but even the few that are in there aren't
|
||||
quite right...this file is mostly a "hack around until it works" effort.
|
||||
|
||||
Knowing that this is an initial effort, care was put into making sure that
|
||||
when a symbol is actually **used** at runtime, the unikernel will crash after
|
||||
posting a message indicating the specific function call that was involved. This
|
||||
is designed to either a) correct the configuration using `kraft menu` or
|
||||
b) provide an implementation directly in `undefined.c`. In some cases, I prefer
|
||||
the implementation in `undefined.c`, most specifically the `write` function,
|
||||
which will output stderr messages in red.
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
|
||||
The build script basically runs these commands:
|
||||
|
||||
```sh
|
||||
|
|
14
build.zig
14
build.zig
|
@ -74,7 +74,7 @@ pub fn build(b: *std.Build) void {
|
|||
const run_step = b.step("run", "Run the app");
|
||||
run_step.dependOn(&run_cmd.step);
|
||||
|
||||
const kraft_clean_cmd = b.addSystemCommand(&[_][]const u8{
|
||||
var kraft_clean_cmd = b.addSystemCommand(&[_][]const u8{
|
||||
"kraft",
|
||||
"clean",
|
||||
"--plat",
|
||||
|
@ -82,6 +82,8 @@ pub fn build(b: *std.Build) void {
|
|||
"--arch",
|
||||
"x86_64",
|
||||
});
|
||||
kraft_clean_cmd.stdio = .{ .check = .{} }; // kraft clean has some weird exit code behavior
|
||||
kraft_clean_cmd.has_side_effects = true;
|
||||
const clean_step = b.step("clean", "Clean the unikraft build");
|
||||
clean_step.dependOn(&kraft_clean_cmd.step);
|
||||
|
||||
|
@ -90,9 +92,17 @@ pub fn build(b: *std.Build) void {
|
|||
"-rf",
|
||||
".unikraft",
|
||||
});
|
||||
|
||||
// rm -rf in this manner is leaving empty .unikraft/build, which is confusing
|
||||
// let's whack it
|
||||
const remove_empties_cmd = b.addSystemCommand(&[_][]const u8{
|
||||
"find", ".unikraft", "-type", "d", "-empty", "-delete",
|
||||
});
|
||||
remove_empties_cmd.step.dependOn(&distclean_cmd.step);
|
||||
|
||||
const distclean_step = b.step("distclean", "Deep clean the unikraft build");
|
||||
distclean_step.dependOn(clean_step);
|
||||
distclean_step.dependOn(&distclean_cmd.step);
|
||||
distclean_step.dependOn(&remove_empties_cmd.step);
|
||||
}
|
||||
|
||||
const LazyPathEnvironmentVariable = struct {
|
||||
|
|
Loading…
Reference in New Issue
Block a user