While debugging, it’s invaluable to be able to trace functions in the Linux
kernel. There are several tools for that task: perf, ftrace (with helper tool
like trace-cmd), bpftrace, etc.
For my own debug of kernel internals and in the last few years to debug the
i915 module for Intel graphics, I usually use tracepoints or dynamic
tracepoints (with perf probe) as the trigger for something I want to trace.
One question I get some times is “how do I trace the initial probe of a
kernel module?”. At that time you (usually) don’t yet have the module …
Embedded Linux boards and devices often come with a shortage of tools
installed. Often enough they don’t use a “normal” Linux distribution that can
be easily extended by the end user by means of installing additional packages
via dnf, apt, pacman, etc. Old/ancient versions of the Linux kernel is also
very common.
In my previous post I wrote
about using evemu to record data coming from the input subsytem and replay
it on my computer in order to develop a Remote Controller software
for ArduPilot. Without surprise, evemu isn’t included in the tools that come
with Disco …
I’m doing some experiments to make the remote controller of Parrot’s Disco
drone (SkyController 2) to work with ArduPilot. I will talk more about this in
another post. This one is basically about a nifty tool I’ve found that I didn’t
know existed: evemu. I always used
evtest to debug the input system in Linux.
SkyController 2 runs Linux and exposes all the sticks and buttons as an evdev
device. I developed a tool to serve as a general-purpose software to be used in
this kind of device: dema-rc. Ultimate
goal is to have a software …
For a long time I have accumulated different configurations for vim for the
different open source projects I’m contributing or have contributed in the past.
It became a giant unmaintained file for ftplugin/ftdetect with regexes to match
the dir name and try to apply every important thing a project needs: from coding
style to commands to build the source code.
After changing my machine and re-installing several softwares, I’m trying to keep
my dotfiles more organized. For vim, after looking at some options available I
settled in this one, that I think is very short and elegant …
Very often I’m in the middle of an interactive rebase and while editing a
commit I remember I should have changed a commit that I initially didn’t mark
on the rebase todo. If you tried to git-rebase again you would notice it’s
not possible due to git’s bookkeeping of the current rebase.
In the past what I usually did was to either 1) Continue the rebase and then
rebase again to fix the previous commit or 2) Create a fixup commit with
git commit --fixup and then rebase again with --auto-squash.