On the Way Towards a Minimal Elementary Based Boot System

2-minute read

Now that I have a working toolchain I also built a full system image for qemu which contains a native toolchain. This avoids the broken by design approach of cross compiling (configure and friends analyze the host system and then based on these wrong assumption draw conclusions about the target system) by using emulation. Of course this also has a price: slower build times.

FWL has a neat trick though which at least in theory should speed up compilation: it uses distcc to call out to the host system (over the virtual network of qemu) where the distccd instance compiles the passed source code with the cross compiler. This means that the CPU intensive compiling process bypasses emulation but the environment dependent steps (./configure etc) are still run within a target environment and therefore can’t leak in bits from the host system.

You might wonder why I said “in theory” above. Well in practice this works best for large compilation units where the overhead of the emulated network and hard disk (I/O) has a smaller influence. And there are also cases where distcc fails to compile something and then falls back to the native compiler (which runs under emulation) if that happens the time spent for distcc is of course wasted. The solution here seems to be throw more/faster hardware at the problem. Unfortunately that’s hardware I currently don’t have. Oh well.

Building a framebuffer based elementary with minimal dependencies

One idea for the boot menu application is to use elementary with the framebuffer backend as a GUI toolkit. This would provide a nice looking touchscreen aware user interface. However I am not really familiar with the whole EFL software stack and therefore don’t know how small/big all required dependencies would be. Some research lead to the following “dependency graph” for elementary:

  • eina
  • eet
    • zlib
    • libjpeg
  • evas
    • freetype
  • ecore
    • ecore-file
    • ecore-evas
    • ecore-input
    • ecore-job
    • ecore-txt
    • libiconv
    • tslib
  • edje
    • embryo
  • libpng

So it seems like this is getting quite complex/large. Maybe link everything static and let the compiler do some magic to eliminate all the unnecessary code paths? Anyway we will see. Spent a few hours configuring every package and disabling lot’s and lot’s of compile time options. During this process I also found some problems in ecore’s touchscreen detection code and submitted the changes back to the enlightenment folks.

Hope this will eventually work in one way or another.

Marc