linux.md

Linux

General knowledge

Configs

The kernel config defines what features the kernel has at build time.
You can view what config you're running on your system right now by running zcat /proc/config.gz
In the future i'll add a place for people to submit their configs to this repo.

Modules

Modules can usually be set to 3 different states:

1. [ ] Disabled - The module will not be built or included and cannot be used later
   
2. [m] Module - The module will be built but will only be loaded or used if needed
   
3. [*] Baked in - The module will always be loaded
   

Disabling features you usually don't use will reduce the time it takes to compile and reduce the size of the kernel.
But it also means that you won't be able to use whatever feature you disabled at a later time without recompiling the kernel.

Modules are great since you can build basically everything and only load what you need and use dynamically.
However this sometimes means you have to rely on initramfs to load storage or filesystem modules.

Baking in modules is usually for good critical or important modules such as storage, filesystems, framebuffer, etc..
Of course baking in everything is a terrible idea as it wastes memory if you're not using something.

Sources & Forks

There are tons of forks out there, Most notably being vendor kernels and mainline forks.
Vendor kernels are typically kernels provided by the OEM to be used by the specific board they provide.
Those forks tend to have device specific configs that only include support for hardware relevant to that platform.

Vendor kernels are sadly known to be very outdated and horrible to use,
You either need an old version of gcc to compile them, Or they outright don't compile at all.

Mainline forks on the otherhand are kernels for development and testing patches before they are sent to mainline.
These kernels tend to use more or less the latest version of linux available at the time.

Helper script

Helper script

Linux compilation is sometimes tedious or annoying, So i wrote a helper script to streamline a bit of that workflow.

Functions:

• build - builds the kernel
• dtb - only compiles/recompiles device trees (In case you made changes)
• cfg - if no argument is specified it will list available kernel configs (eg: defconfig) otherwise it will load the specified config
• config - shows a configuration menu
• generate - generates the necessary files for installation
• install - installs the kernel
• update - updates the kernel repository
• patch - applies a patch from a mailing list
• clean - cleans the build

Features:

• automatic cross compilation - You need to run kbuild.sh clean if you start compiling on one arch and continue on another
• native optimizations - There are some compile flags that are specific to some architectures
• device profiles - Builds are separated into their own folder allowing you to build different kernels for different devices from the same repository

Note
When creating a profile the native optimizations will use what's appropriate for the machine running the command.
So generate device_profile on the target machine and copy it to the compiler machine.

Note
When generating the kernel files it will copy everything you need to /tmp/kernel. (Device tree support will come soon)
You can then copy those files to your target device.

Compiling

Compiling

1. Start by downloading or cloning a kernel.
   git clone --depth 1 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
   

2. Navigate to the kernel directory.
   cd linux

3. Generate device_profile by running.
   kbuild.sh

4. List and select a config.
   kbuild.sh cfg then kbuild.sh cfg yourconfig (eg. defconfig)
   

5. (Optional) Customize the kernel.
   kbuild.sh config

6. Compile the kernel.
   kbuild.sh build

7. Generate necessary files.
   kbuild.sh generate

8. (Optional) Install to the current running system.
   kbuild.sh