I've compiled nebulet, following the directions in README.md, and with a few minor adjustments I had qemu booting. If I make a debug (non --release) build, it freezes with this log:
in sipinit path "e1000.wasm" path "ps2.wasm" path "sipinit.wasm" path "vga.wasm"
and if I do a release build, it crashes with an Option unwrapped on None, with the panic handled by nebulet's panic handler. I was able to connect gdb to qemu remotely with gdbserver, and after telling gdb it's debugging the nebulet binary, got a meaningless backtrace:
is this a known issue, or have I not set things up correctly?
#0 0x00000000002f9121 in rust_begin_unwind () #1 0x0000000000329000 in ?? () #2 0x0000000080110de8 in ?? () #3 0x00000000002f6d50 in ?? () #4 0x0000000000337cf8 in ?? () #5 0x0000000000000002 in ?? () #6 0x00000000002120d8 in ?? () #7 0x0000000000000001 in ?? () #8 0x0000000080110da8 in ?? () #9 0x0000000000000001 in ?? () #10 0x0000000080110e30 in ?? () #11 0x0000000000000000 in ?? ()
Same backtrace, but with the debug nebulet's binary's symbols. (i don't know why this works, since i ran a release build, but the two functions at the top make sense)
#0 0x00000000002f9121 in hashmap_core::map::pop_internal (starting_bucket=...) at /home/magnus/.cargo/registry/src/github.com-1ecc6299db9ec823/hashmap_core-0.1.9/src/map.rs:483 #1 <hashmap_core::map::OccupiedEntry<'a, K, V>>::remove_entry (self=...) at /home/magnus/.cargo/registry/src/github.com-1ecc6299db9ec823/hashmap_core-0.1.9/src/map.rs:2149 #2 0x000000000000006b in ?? () #3 0x0000001500000163 in ?? () #4 0x0000000080110e68 in ?? () #5 0x0000000000000001 in ?? () #6 0x0000000000000000 in ?? ()
sipinit.wasmand sometimes it randomly can't find it.
Hey @robert-w-gries, thanks for asking.
I suppose the answer is that I'm not sure. In some ways, I feel like I'm in a different stage of my life right now, and that I've moved on.
That being said, I really believe in the vision of nebulet. I think that this kind of operating system is the future. Maybe it's a little too forward thinking.
I'd be happy to give you write access to the nebulet organization if you'd like to continue work on it.
nebulet, but I think there will come a point where my work with
rXinuis done and I'll want to dedicate my rust osdev work towards
nebulet. I share a similar belief in the concept behind
nebulet, and I'm sure there will always be someone willing to work on it.