Google Working On New "Fuchsia" Operating System, Powered By Magenta / LK Kernel

[EduRam]

Fuchsia documentation is taking shape.

https://fuchsia.googlesource.com/doc...AD/glossary.md

Interesting reading is about "namespace spec".

[aanno]

It seems to be possible to build the whole stuff, but I only find my way halfway through:

fuchsia$ ./scripts/build-sysroot.sh -c

Fails with:

[30/36] Linking CXX shared library lib/libc++.so
FAILED: lib/libc++.so
: && /home/tpasch/compile/fuchsia/buildtools/toolchain/clang+llvm-x86_64-linux/bin/clang++ -fPIC -target x86_64-fuchsia --sysroot=/home/tpasch/compile/fuchsia/out/sysroot/x86_64-fuchsia -O3 -DNDEBUG /home/tpasch/compile/fuchsia/buildtools/toolchain/clang+llvm-x86_64-linux/lib/clang/4.0.0/lib/fuchsia/libclang_rt.builtins-x86_64.a -target x86_64-fuchsia --sysroot=/home/tpasch/compile/fuchsia/out/sysroot/x86_64-fuchsia -fPIC -nodefaultlibs -shared -o lib/libc++.so lib/CMakeFiles/cxx_objects.dir/__/src/shared_mutex.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/chrono.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/typeinfo.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/iostream.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/system_error.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/string.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/future.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/debug.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/stdexcept.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/any.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/algorithm.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/bind.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/strstream.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/thread.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/ios.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/locale.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/random.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/optional.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/condition_variable.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/exception.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/regex.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/utility.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/valarray.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/hash.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/mutex.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/new.cpp.o lib/CMakeFiles/cxx_objects.dir/__/src/memory.cpp.o -lc++abi -lpthread -lc -lm -lunwind && cd /home/tpasch/compile/fuchsia/out/build-libcxx-x86_64/lib && /usr/bin/python /home/tpasch/compile/fuchsia/third_party/llvm/projects/libcxx/utils/gen_link_script/gen_link_script.py /home/tpasch/compile/fuchsia/out/build-libcxx-x86_64/lib/libc++.so c++abi unwind
symlink file /home/tpasch/compile/fuchsia/out/build-libcxx-x86_64/lib/libc++.so is not a symlink
ninja: build stopped: subcommand failed.

Perhaps this is a starting point for somebody else to try.

Cheers,

aanno

PS:

This is a small receipt of what I done:

Read:

https://fuchsia.googlesource.com/jiri

https://fuchsia.googlesource.com/manifest/+/master/README.md

https://fuchsia.googlesource.com/fuchsia/+/HEAD/README.md

--

install golang, bison, flex

--

In .bashrc:

# fuchsia stuff (tp)
export MY_ROOT=/home/tpasch/compile/fuchsia
export PATH="$MY_ROOT"/.jiri_root/scripts:"$MY_ROOT"/.jiri_root/bin:$PATH

--

. ~/.bashrc
cd "$MY_ROOT"
curl -s https://raw.githubusercontent.com/fu...bootstrap_jiri | bash -s "$MY_ROOT"

--

jiri import minimal https://fuchsia.googlesource.com/manifest
jiri update

--

jiri import fuchsia https://fuchsia.googlesource.com/manifest
jiri update

--

./scripts/build-toolchain.sh -c

cmake problem with libssl.so.1.0.0:

cd ./buildtools/cmake/bin
mv cmake cmake.old
ln -s /usr/bin/cmake .

--

./scripts/build-sysroot.sh -c

cmake problem: symlink file /home/tpasch/compile/fuchsia/out/build-libcxx-x86_64/lib/libc++.so is not a symlink

??? GOTCHA ???

-

CMake Warning:
Manually-specified variables were not used by the project:

LLVM_ENABLE_LIBCXX

cd ./third_party/llvm/projects/libcxx/src/

add to CMakeLists.txt line 21 (after the other set):
set(ignoreMe "${LLVM_ENABLE_LIBCXX}")

[nasyt]

First, it struck me as strange, but I think, that there is a lot of potential. IMHO the kernel is very easy to extend. All of this stuff is really clean and really good.

[nasyt]

I am excited.

[Xaero_Vincent]

Has anyone here tried Fuchsia yet?

I tested Fuchsia out the other day and posted a video on youtube. It's very much in early development stage but does have a graphics console and basic support for graphics.

Someone managed to get the vMac emulator complete with MacOS System 5 ported to Fuchsia, which is pretty cool. It's like the classic late 1980's Macintosh UI is the first real desktop environment for Fuchsia.

http://i.imgur.com/zEa1XcY.png

[starshipeleven]

Hmm, wait, I didn't get, what are advantages of running a kernel from a kernel?

In embedded it's more obvious, but also in x86 it's the same.
In your mobo there are low-level firmwares that get loaded by the boot ROM (a real ROM present in the chipset usually) to initialize the hardware and even UEFI board firmware is only a payload on top of a chain.

The boot chain loads and executes more and more complex firmwares at each step until it reaches what can be called operating system. UEFI for example is a tiny operating system with full network stack, and you can code games for it (or boot managers like rEFInd or the monstruosity that GRUB UEFI is nowadays).

In general, most modern hardware is initialized at low-level by these things, linux kernel (or any other OS) is unable to actually initialize cold hardware.

[duby229]

But a usual Grub, which is bootloader, have all of it either, isn't it? Except for fastboot, just because it is Android specific thing.

Yeah, you're right. But really if you think about it, grub is a bit more than a bootloader.

[Hi-Angel]

I'd say it's a bit more than that. It loads things like framebuffer or USB and sd/mmc drivers. It allows fastboot to run (pwr+vol-down). That has scriptable menus so things like factory reset or multiboot can be set up early on before kernel loads.

But a usual Grub, which is bootloader, have all of it either, isn't it? Except for fastboot, just because it is Android specific thing.

[duby229]

Ah, I see, so LittleKernel, at least in Android, is nothing more than a bootloader.

I'd say it's a bit more than that. It loads things like framebuffer or USB and sd/mmc drivers. It allows fastboot to run (pwr+vol-down). That has scriptable menus so things like factory reset or multiboot can be set up early on before kernel loads.

[Hi-Angel]

Ah, I see, so LittleKernel, at least in Android, is nothing more than a bootloader.