System functionality

From Wikibooks, open books for an open world
Jump to navigation Jump to search

This article describes infrastructures used to support and manage other kernel functionalities. This functionality is named after system calls and sysfs.

User space interfaces, System calls
Driver Model
buses, PCI
hardware interfaces, [re]booting

User space communication[edit | edit source]


⚲ APIs:

📚 References

System calls[edit | edit source]

⚙️ Internals:

📚 References

💾 Historical

Device files[edit | edit source]

Classic UNIX devices are Char devices used as byte streams with man 2 ioctl.

⚲ API:

ls /dev
cat /proc/devices 
cat /proc/misc

Examples: misc_fops id usb_fops id memory_fops id

hiddev[edit | edit source]

hiddev isn't real human interface device. Is reuses USBHID infrastructure. hiddev is used for example for monitor controls and Uninterruptible Power Supplies. This module supports these devices separately using a separate event interface on /dev/usb/hiddevX (char 180:96 to 180:111) (⚙️ HIDDEV_MINOR_BASE id)

⚲ API:

⚙️ Internals:

📚 References:

📚 References:

Administration[edit | edit source]


📚 References

procfs[edit | edit source]

The proc filesystem (procfs) is a special filesystem that presents information about processes and other system information in a hierarchical file-like structure, providing a more convenient and standardized method for dynamically accessing process data held in the kernel than traditional tracing methods or direct access to kernel memory. Typically, it is mapped to a mount point named /proc at boot time. The proc file system acts as an interface to internal data structures in the kernel. It can be used to obtain information about the system and to change certain kernel parameters at runtime.

/proc includes a directory for each running process —including kernel threads— in directories named /proc/PID, where PID is the process number. Each directory contains information about one process, including the command that originally started the process (/proc/PID/cmdline), the names and values of its environment variables (/proc/PID/environ), a symlink to its working directory (/proc/PID/cwd), another symlink to the original executable file —if it still exists— (/proc/PID/exe), a couple of directories with symlinks to each open file descriptor (/proc/PID/fd) and the status —position, flags, ...— of each of them (/proc/PID/fdinfo), information about mapped files and blocks like heap and stack (/proc/PID/maps), a binary image representing the process's virtual memory (/proc/PID/mem), a symlink to the root path as seen by the process (/proc/PID/root), a directory containing hard links to any child process or thread (/proc/PID/task), basic information about a process including its run state and memory usage (/proc/PID/status) and much more.

📚 References

sysfs[edit | edit source]

sysfs is a pseudo-file system that exports information about various kernel subsystems, hardware devices, and associated device drivers from the kernel's device model to user space through virtual files. In addition to providing information about various devices and kernel subsystems, exported virtual files are also used for their configuring. Sysfs is designed to export the information present in the device tree, which would then no longer clutter up procfs.

Sysfs is mounted under the /sys mount point.

⚲ API:

📚 References

devtmpfs[edit | edit source]

devtmpfs is a hybrid kernel/userspace approach of a device filesystem to provide nodes before udev runs for the first time.

📚 References

Driver Model[edit | edit source]

or Device Model, or just DM. DM core structure consists of DM classes, DM buses, DM drivers and DM devices.


⚲ Infrastructure API:

Classes[edit | edit source]

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. General DM classes structure match composite pattern.

⚲ API:

👁 Examples: input_class id, block_class id net_class id

Buses[edit | edit source]

A peripheral bus is a channel between the processor and one or more peripheral devices. A DM bus is proxy for a peripheral bus. General DM buses structure match composite pattern. 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:

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

Drivers[edit | edit source]

⚲ API:

👁 Examples: hid_generic id usb_register_device_driver id

Platform drivers

👁 Examples: gpio_mouse_device_driver id

Devices[edit | edit source]

⚲ API:

👁 Examples: platform_bus id mousedev_create

Platform devices

👁 Examples: add_pcspkr id


  • 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:

📚 References

Modules[edit | edit source]

cat /proc/modules

📚 References

Peripheral buses[edit | edit source]

⚲ API:

  • Shell interface: ls /proc/bus/ /sys/bus/

See also Buses of Driver Model

See Input: keyboard, mouse etc


⚲ Shell API:

  • lspci -vv
  • column -t /proc/bus/pci/devices

Main article: PCI


⚲ Shell API:

  • lsusb -v
  • ls /sys/bus/usb/
  • cat /proc/bus/usb/devices

⚙️ Internals:

📚 References:

Other buses

Buses for 🤖 embedded devices:

Hardware interfaces[edit | edit source]


I/O ports and registers[edit | edit source]

⚲ 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[edit | edit source]

Keywords: firmware, hotplug, clock, mux, pin

⚙️ Internals:

📚 References

Booting and halting[edit | edit source]

Kernel booting[edit | edit source]

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).

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.

↯ Startup call hierarchy:

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 ramdisk (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:

Halting or rebooting[edit | edit source]


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

Building and Updating[edit | edit source]