Interview with eng.stk, Developer of blu_spark Kernel – Part 1: Origins and Kernel Development

We may earn a commission for purchases made using our links.

I recently got the chance to interview XDA Senior Member eng.stk, developer of the blu_spark kernel. It’s available across many devices on our forums, including the Nexus 5, OnePlus 3/T and the OnePlus 5T. In this part, we ask eng.stk about his origins in development and how he develops the blu_spark kernel.

So first, introduce yourself and your kernel. How does your kernel differentiate itself from the competition? What is your design philosophy for kernel changes, and how do you go about them?

I’m eng.stk and I’ve been around on XDA since 2010. Most of you know me from my code_blue and blu_spark projects 🙂 I started on XDA by writing some scripts and miscellaneous tools, framework hacks. I’ve done lots of theming also… During my time here I have also directly collaborated to some projects like Purity ROM, Universal Kernel Manager, Kernel Adiutor and more recently Magisk and WireGuard just to name a few. I’ve been doing some TWRP work lately also (especially on OnePlus devices), Magisk modules and other tools/hacks [that are] useful during the life cycle of my kernel projects (some stuff went on the XDA Portal if I recall correctly). blu_spark kernel started to become not only a kernel, but an all-around experience between kernel, toolchains, recovery, theming, tools, scripts, etc. But kernel work is what I enjoy the most and what drives me. I always enjoyed hacking around and building some code/scripts when I had the chance (disassembling electronic toys and basic coding on my cousin’s Commodore 64 was fun). For me coding is not a means to an end but just a tool like some others to achieve a defined purpose. Most of my more serious stuff and foundations of my work were done when I discovered Linux during my adolescence/early twenties. Later on, somewhere during University times, Android was the logical next step for me: a tinkerer’s dream really, where hardware or software could be played with a lot. The best words to describe blu_spark are optimization and stability. People who use it know that they can rely on it. My kernel builds are somewhat ‘stockish’ in a way that I tend not to remove some stuff available out of the box, keeping everything optional so that people can choose. I don’t like adding too much stuff, I just change or add what I consider the best for each given field. The CPU freq driver, the IO scheduler, the network protocols, the filesystems etc or tweak some tunables for some given parameters or upstream some drivers for the best possible outcome. I also build custom made toolchains (from Linaro, awesome take on GCC), mainly to get the best out of the architecture. Bottom line, most people know that they are on blu_spark from the moment they flash the kernel on device. I’m always looking for new stuff and ways to give the best UX possible. Safely.

Tell us about your blu_active governor! What is it, what does it do and why is it special?

I know people sometimes confuse blu_active with blu_spark. blu_active is just a small part compared to all of the rest [of the work] that I do. The CPU governor basically makes decisions to make CPU frequencies go up or down, according to the needs of the system. The governor has had several changes and mutations since it started. Like everything else I do, I needed something that fulfilled my needs. It is based on my favorite governor, the interactive governor. At the beginning I just put some upstream stuff on it, but then I started adding some other stuff, like CAF updates or logic I had seen in other governors that I find useful. I also added HMP compatibility and some other goodies. The latest iteration is based on Google’s Linux 4.4 Android branch, with some upstream and CAF fixes also, but much more leaner than before. Simply use what you have to the full, remove what you don’t. I always try to get better battery than with stock settings, reducing drain, while trying to improve performance (real life performance, the one that you feel with your eyes and fingers, not with synthetic tools). At one point in time, I wanted a simple tunable so people could play around with performance in a simple way. This is how Fastlane was born :). The logic is somewhat similar to the way Honda VTEC works: play with timings from a given threshold. So, with a simple switch and a variable threshold value, people could have a more direct and aggressive cpu freq scaling. Making it enter sooner or later according to system load, bypassing target loads. It’s fully compatible with HMP and can be tweaaked per cluster according to people needs, finely tuned for each device it runs on.

What built-in mechanisms or tweaks do you like/dislike that OEMs provide? ie Qualcomm’s input boost.

Some userspace boosts and other tunables that are set in HALs (Hardware Abstraction Layers), hardcoded framework stuff etc, can sometimes be annoying. Of course, kernel developers are known to work around some of those On the Nexus 5, for example, most of us got rid of mpdecision and got a custom hotplug – we had blu_plug in place at the time. Some other devices had bad thermal management and a custom thermal control with sysfs for temp levels, mitigation frequency etc. Some more recent devices have some hard policies on battery, unplugging cores and other stuff in “low levels” that didn’t make a real gain in device usage. As a matter of fact, it even ruined user experience sometimes, so it was necessary to tame down CTL and BCL technologies. I also remember removing encryption in devices when that was a thing, all the changes SELinux iterations introduced changes that made previous hacks done work in a different way… some recent Android security changes are a constant challenge. These include AVB (some parts mostly know as dm-verity). Some other changes have made restrictions for tunables and sysfs places that had to be moved because we don’t have access to the same places we had before. Most of these restrictions are more relevant for stock ROMs (in which I do most of my work), normally it paves the road and makes it easier when it comes to custom ROMs (where restrictions are lower). In recent SoCs like the Qualcomm Snapdragon 820 and 835, some OEMs have added some boosts from userspace that are welcome and tackle blind spots in the system, not all OEM stuff is bad. When it comes to kernel source, the cleaner and more documented the source is, the better.

What other features do you like to include? Such as advanced colour control, and so on.

I normally don’t include stuff I don’t personally use or that I don’t find it useful. Stuff I like to do, besides blu_active, includes architecture optimizations and fixes, crypto stuff updates, IO scheduling and other storage/filesystem goodies, KCAL, USB fast charge, vibration strength, battery/notification LED control,Wakelock blockers, WireGuard, etc. I always build with a custom build toolchain like I said earlier on.

What testing methodology do you use for your kernel? Do you use user reports, or benchmarks or any other custom routines?