Kernel booting

This is loaded in two stages - in the first stage the kernel (as a compressed image file) is loaded into memory and decompressed, and a few fundamental functions such as essential hardware and basic memory management (memory paging) are set up. Control is then switched one final time to the main kernel start process calling start_kernel _id, which then performs the majority of system setup (interrupts, the rest of memory management, device and driver initialization, etc.) before spawning separately, the idle process and scheduler, and the init process (which is executed in user space).

Kernel loading stage

The kernel as loaded is typically an image file, compressed into either zImage or bzImage formats with zlib. A routine at the head of it does a minimal amount of hardware setup, decompresses the image fully into high memory, and takes note of any RAM disk if configured. It then executes kernel startup via startup_64 (for x86_64 architecture).

• arch/x86/boot/compressed/vmlinux.lds.S _src - linker script defines entry startup_64 _id in
• arch/x86/boot/compressed/head_64.S _src - assembly of extractor
• extract_kernel _id - extractor in language C
  • prints

Decompressing Linux... done.
Booting the kernel.

Kernel startup stage

The startup function for the kernel (also called the swapper or process 0) establishes memory management (paging tables and memory paging), detects the type of CPU and any additional functionality such as floating point capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel _id.

• arch/x86/kernel/vmlinux.lds.S _src - linker script
• arch/x86/kernel/head_64.S _src - assembly of uncompressed startup code
• arch/x86/kernel/head64.c _src - platform depended startup:
  • x86_64_start_kernel _id
  • x86_64_start_reservations _id
• init/main.c _src - main initialization code
  • start_kernel _id 200 SLOC
    • rest_init _id
      • kernel_init _id - deferred kernel thread #1
        • kernel_init_freeable _id This and following functions are defied with attribute __init _id
          • prepare_namespace _id
            • initrd_load _id
            • mount_root _id
        • run_init_process _id obviously runs the first process man 1 init
      • kthreadd _id - deferred kernel thread #2
      • cpu_startup_entry _id
        • do_idle _id

start_kernel _id executes a wide range of initialization functions. It sets up interrupt handling (IRQs), further configures memory, starts the man 1 init process (the first user-space process), and then starts the idle task via cpu_startup_entry _id. Notably, the kernel startup process also mounts the initial RAM disk (man 8 initrd) that was loaded previously as the temporary root file system during the boot phase. The initrd allows driver modules to be loaded directly from memory, without reliance upon other devices (e.g. a hard disk) and the drivers that are needed to access them (e.g. a SATA driver). This split of some drivers statically compiled into the kernel and other drivers loaded from initrd allows for a smaller kernel. The root file system is later switched via a call to man 8 pivot_root / man 2 pivot_root which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible. The memory used by the temporary root file system is then reclaimed.

📚 References

• Article about booting of the kernel
• Initial RAM disk _doc
• Linux startup process
• init
• http://tldp.org/HOWTO/Linux-i386-Boot-Code-HOWTO/
• http://www.tldp.org/LDP/lki/lki-1.html
• http://www.tldp.org/HOWTO/KernelAnalysis-HOWTO-4.html
• IBM description of Linux BIOS boot process
• Linux (U)EFI boot process
• Linux kernel boot parameters
• kernel parameters _doc
• Kernel booting process
• Kernel initialization process

Halting and rebooting

🔧 TODO

⚲ API: sys_reboot _id calls machine_restart _id or machine_halt _id or machine_power_off _id

• Softdog Driver

System calls

• Table of syscalls

⚙️ Internals:

• linux/syscalls.h _inc
• syscall_init _id
• entry_SYSCALL_64 _id
• do_syscall_64 _id
• man 2 syscall
• man 2 syscalls

📚 References

• System call
• Directory of system calls, man section 2
• Anatomy of a system call, part 1 and part 2
• syscalls _ltp

💾 Historical

• ULK3 Chapter 10. System Calls

Administration

🔧 TODO

📚 References

• man 7 netlink
• The Linux kernel user’s and administrator’s guide _doc

Classes

A class is a higher-level view of a device that abstracts out low-level implementation details. Drivers may see a NVME storage or a SATA storage, but, at the class level, they are all simply block_class _id devices. Classes allow user space to work with devices based on what they do, rather than how they are connected or how they work.

⚲ API:

• ls /sys/class/
• class_register _id registers class _id
• linux/device/class.h _inc

👁 Examples: input_class _id, block_class _id net_class _id

Buses

A bus is a channel between the processor and one or more devices. For the purposes of the device model, all devices are connected via a bus, even if it is an internal, virtual, platform_bus_type _id. Buses can plug into each other. A USB controller is usually a PCI device, for example. The device model represents the actual connections between buses and the devices they control. A bus is represented by the bus_type _id structure. It contains the name, the default attributes, the bus' methods, PM operations, and the driver core's private data.

⚲ API:

• ls /sys/bus/
• bus_register _id registers bus_type _id
• linux/device/bus.h _inc

👁 Examples: usb_bus_type _id, hid_bus_type _id, pci_bus_type _id, scsi_bus_type _id, platform_bus_type _id

• Buses

Drivers

⚲ API:

• ls /sys/bus/*/drivers/
• module_driver _id - simple common driver initializer, 👁 for example used in module_pci_driver _id
• driver_register _id registers device_driver _id - basic device driver structure, one per all device instances.
• linux/device/driver.h _inc

👁 Examples: hid_generic _id usb_register_device_driver _id

Platform drivers

• module_platform_driver _id registers platform_driver _id (platform wrapper of device_driver _id) with platform_bus_type _id
• linux/platform_device.h _inc

👁 Examples: gpio_mouse_device_driver _id

Devices

⚲ API:

• ls /sys/devices/
• device_register _id registers device _id - the basic device structure, per each device instance
• linux/device.h _inc

👁 Examples: platform_bus _id mousedev_create

Platform devices

• platform_device _id - platform wrapper of struct device - the basic device structure _doc, contains resources associated with the devie
• it is can be created dynamically automatically by platform_device_register_simple _id or platform_device_alloc _id. Or registered with platform_device_register _id.
• platform_device_unregister _id - releases device and associated resources

👁 Examples: add_pcspkr _id

⚲ API: 🔧 TODO

• platform_device_info platform_device_id platform_device_register_full platform_device_add
• platform_device_add_data platform_device_register_data platform_device_add_resources
• attribute_group dev_pm_ops

⚙️ Internals:

• drivers/base/platform.c _src
• drivers/base/core.c _src

📚 References

• Device drivers infrastructure _doc
• Driver Model _doc
  • The Linux Kernel Device Model _doc
  • Platform Devices and Drivers _doc
• linux/kobject.h _inc
• Linux Device Model, by linux-kernel-labs

I/O ports and registers

⚲ API:

ioport_map _id

ioread32 _id/ iowrite32 _idetc

linux/ioport.h _inc:

request_mem_region _id

Functions for memory mapped registers:

ioremap _id

readl _id/ writel _idetc

The {in,out}[bwl] macros are for emulating x86-style PCI/ISA IO space:

inl _id/ outl _idetc

Hardware Device Drivers

Keywords: kobjects, sysfs, buses, devices, drivers, classes, firmware, hotplug, gpio, pin, clock, mux

⚙️ Internals:

• drivers/acpi/ _src
• drivers/base/ _src
• drivers/virtio/ _src

📚 References

• Pin control subsystem _doc
• Linux Hardware Monitoring _doc

• LDD3:The Linux Device Model

• http://www.tldp.org/LDP/tlk/dd/drivers.html
• http://www.xml.com/ldd/chapter/book/
• http://examples.oreilly.com/linuxdrive2/