Working on AArch64 often means changing code in some projects. I did that so many times that I am unable to say where I have some commits. Such thing got a name: drive-by coding.
Definition
Drive-by coding is situation when you appear in some software project, do some changes, get them merged and then disappear to never be seen again.
Let’s build something
All starts from simple thing: I have/want to build some software. But for some reason it does not cooperate. Sometimes it is simple architecture check missing, sometimes atomic operations are not present, intrinsics are missing or anything else.
First checks
Then comes moment of looking at build errors and trying to work out some solution. Have I seen that bug before? Does it look familiar?
If this is something new then quick Google search for error message. And checking bug reports/issues on project’s website/repo. There can be ready to use patches, information how to fix it or even some ideas why does it happen.
If this is system call failure in some tests then I check my syscalls
table are those ones handled
on aarch64 and try to change code if they are not (legacy ones like open,
symlink, rename).
Simple fixes
When I started working with AArch64 (in 2012) there were moments when many projects were easy to fix. If atomics were issue then copying them from Linux kernel was usually solution (if license allowed).
Architecture checks with pile of #ifdef __X86_64__ or similar ones which are
trying to do decide for simple things like “32/64” or “little/big endian”.
Nowadays such ones do not happen as often as it was.
SIMD intrinsics can be a problem. All those vst1q_f32_x2(), vld1q_f32_x2 and
similar. I do not have to understand them to know that it usually means that C
compiler lacks some backports as those functions were added into gcc and llvm
already (like it was with Pytorch recently).
Complex stuff
There are moments when getting software to build needs something more complicated. Like I wrote above, I usually start with searching for error message and checking was it an issue in some other projects. And how it got solved. If I am lucky then patch can be done in short time and send for review upstream (once it builds and passes tests).
Sometimes all I can do is reporting issue upstream and hope that someone will care enough to respond. Usually it ends with at least discussion on potential ways to fix, sometimes hints or even patches to test.
Projects response
Projects usually accept patches, review them and merge. In several cases it took longer than expected, sometimes there was larger amount of those so they remember me (at least for some time). It helps when I have something for those project again months/years later.
There are projects where I prefer to forget that they exist. Complicated contribution rules, crazy CI setup, weird build systems (ever heard about ‘bazel’?). Or comments in ‘we do not give a shit about non-x86’ style (with a bit polished language). Been there, fixed something to get stuff working and do not want to go back.
Summary
‘Drive-by coding’ reminds me going abroad for conferences. People think that you saw interesting places when in reality you spent most of time inside of hotel and/or conference centre.
It is similar with code. I was in several projects, usually had no idea what they do, how they work. Came, looked shortly, fixed something and went back home.
