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?
I own every phone that I develop for, so any changes are always tested be me. Since I daily drive every device for a long time period, anything I find not fit for me, shouldn’t be fit for anybody else. When I publicly release a build, it has already had lots of testing from me and some other people that I trust to provide useful feedback. I know sometimes some users get bored from constantly having all the things working like it should, but I value stability above all: I always put myself on the shoes of a user in the first place.
I run things towards a real life use case, not synthetic tests. This kind of software is made for humans, not machines in a back office. The start point is always better than stock experience, on all fronts, but I don’t really value the latest Antutu high score that much. My kernels can be tuned to this kind of benchmark, but it’s not my end goal. I do value some benchmarks that are more direct, like IO storage testing for instance. They can give a fast way to assert some changes recently done for example.
I do my testing with stock ROMs so that I can have a stable baseline for things. I do custom builds for custom ROMs, but due to volatile nature of custom ROMs with added extras, nightlies and even implementation difference on some features, it’s impossible to cover them all and give proper support to everybody, unfortunately.
I also sometimes build beta builds to test something specific or for when I launch builds to Beta ROMs or developer previews. I did that on the Nexus and OnePlus devices, people like to test stuff out sometimes
Check out part 2: F2FS, EAS and Tips for Aspiring Kernel Developers
from xda-developers http://ift.tt/2kRhY9f
via IFTTT
Aucun commentaire:
Enregistrer un commentaire