boot/gui: Use libffi rather than bespoke bindings #149
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Thus re-using buildInputs from gems, thus closing the circle.
Bindings to libffi, with (approximatively) the same API as the Ruby Fiddle stdlib. This uses a fork with fixes, and hopefully improvements and maintainership in the future.
Otherwise we lose dependency management on transitive dependencies.
samueldr
force-pushed
the
feature/lvgui-ffi
branch
from
31f368a
to
98b06a8
Compare
Can be launched with `DEBUGGER="gdb --args" ./result/bin/simulator`.
samueldr
force-pushed
the
feature/lvgui-ffi
branch
from
98b06a8
to
01a2488
Compare
This ends up saving ~100KiB. Not much, but we're already 1MiB over the ~7-8 MiB budget. Though, in reality, it's not for the space saving, but because dlopen/dlsym will be needed for ffi-based bindings.
Main changes are: * Dynamic build support * Minimal introspection * "better" makefile which handles the .pc file
samueldr
force-pushed
the
feature/lvgui-ffi
branch
from
01a2488
to
cebc037
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a mostly transparent change.
This uses the updated
mruby-lvguithat usesmruby-fiddle, which useslibffirather than writing bespoke bindings for LVGL.Why make this change if it changes nothing? To reduce the surface of mistakes. I am not a C developer. Probably always be uneasy writing C. Some bits of the bindings already were iffy.
The only bit I'm not happy with, but I am satisfied with, is the struct bindings. Fiddle does not have a way to describe nested structs. (Neither does the ruby mainline Fiddle.) LVGL uses nested structs for styles. To work around the issue, accessor functions in C have been generated. It's not clean, but it's working in a correct manner, which for the best.
It already was an issue with the previous bindings, and still is with the Fiddle-based bindings, there is no proper deallocation / destruction for LVGL objects. Not much of an issue for what can be called "short lived applications", but still something to get fixed for correctness in the future.
But still, why? The code worked, and seemingly was right. Let's gloss over "seemingly", and go to a more useful reason. Using FFI bindings, rather than relying on a spaghetti mess of generated code for bespoke bindings, should allow us to more easily implement the missing functionality from LVGL, and doing it correctly.
Furthermore, having everything prepared for FFI bindings gives us freedom for non-LVGL related things. The
key-heldapplet should be retooled to use FFI bindings on evdev, rather than rely on a hack using theevtestcommand.Other notable changes
Bloat?
The initrd doesn't use
pkgsStaticanymore. Fiddle usesdlsymto discover symbols by name, and this doesn't work with a static musl libc.This doesn't bloat the initrd, compressed or not. The compressed boot image for
asus-z00tis now smaller.The main space consumer is systemd libraries, used by udev, which already were using "normal" glibc builds, so this is why there is no bloating; everything pretty much already was in there.