Easylkb: Easy Linux Kernel Builder(tmpout.sh) |
Easylkb: Easy Linux Kernel Builder(tmpout.sh) |
I've recently wanted to start building Linux kernels and play with device drivers again. Wanted to build and then execute on top of QEMU. Downloaded, configured, and built Linux kernel 6.6 following recipes from arch and a few other places. Doing a reasonable .config was a painful process (picking what to include etc.) The kernel build took several hours. The resulting image refused to boot under Virtual Machine Manager, to say nothing of using gdb etc. to interactively debug the kernel.
So, I figured I was looking at a solid weekend of googling, stack-overflowing, swearing, reading kernel Documentation files etc. and finally getting everything set up and working happily.
NOT! The easylkb script did the entire thing completely automatically, culminating in a login prompt on a running virtual machine!! The Linux kernel .config was one of the standard ones I believe, but I hadn't yet found it. The complete kernel build took on the order of several minutes instead of several hours.
There were a couple of minor issues I had with easylkb, which I will share as comments on github.
make help | less
make defconfig
make menuconfig
This and much more is covered in
Distro kernels are normally quite "full fat" so this may tend to build a lot, but it's a good way to get a kernel which closely matches what you're typically running, both in terms of device coverage and compilation options / hardening.
Something I have been surprised about is how much functionality exists in the Linux kernel and how much more reliable the modules are compared to many user-space tools (e.g. race-conditions).
This script may just be what I needed to start.
The Linux Foundation has similar offerings but 3x more expensive, less time, and online only https://training.linuxfoundation.org/linux-kernel-developmen...
"Understanding the Linux kernel", and "Linux device drivers" are pretty good, pragmatic books IMHO to give you a solid understanding of most useful subsystem.
As for this kernel building script, I guess it could be handy, but unless you're hacking very frequently I never found the actual build of the kernel to be the more cumbersome part.
I'm toying with building a little OS using the Linux kernel and an all-Go userspace, and one of the goals is to make the entire system as easy to cross-compile (both host OS and host/guest CPU arch) as possible. Linux being non-trivial to compile (let alone cross-compile) has been so far quite a nuissance, so I'll definitely be having a closer look at this.
Targets mostly at single board computers, and I think it downloads pre-built kernels (and bootloaters if needed), rather than trying to build them directly, since getting a working cross compilation toolchain set up and plumbed into the kernel compilation process is still a pain.
I've personally only used yocto/open-embedded for that which does nicely handle building the cross-compilation toolchain, kernel image, and modules. But it is kinda overkill for that task, being designed to build a whole userland too.
The ultimate goal is to make it very straightforward to change any part of the system source and try it out in action, so the only things you need installed to get started are Go and Qemu. Further down the road I'd love to extend these principles to hacking the kernel - I'd probably like a simpler kernel, maybe OpenBSD or NetBSD, but I'm less familiar with those.
It uses musl and builds using a musl cross compiler, working x86 and arm64 builds. You could easily build a toolchain for your desired arch and make a simple distro, adding in any user space tools.
As an aside, I was astonished that the build took less than 100s. My recollection is that this took about an hour on on my previous system (I7-4770K, 32GB RAM and SATA SSD formatted with ZFS.) New system is Ryzen 7 7700X, 32GB RAM and NVME SSD. I expected a performance boost, but not that much. I'm still wondering what I did wrong/differently.
Doesn't kernel use incremental builds? All well-designed C projects that I know of compile .c files into .o files and link them, so a single file modification only requires a single recompilation/relinking.
I'm not sure that a lot of people who don't work with make realize that it's smart enough to only rebuild what has changed, and that it's not just a command runner!