Linux General Concepts

Internal

• Linux

Kernel

Kernel Concepts

Process

A process is an operating system level construct that holds all the resources an application maintains and uses at runtime. These resources include, but are not limited to a memory address space, file handles, devices and threads. Each process contains at least one thread, and the initial thread for the process is called the main thread. When the main thread terminates, the process, and subsequently, the application, application terminates.

Execution Context

An execution context represents the means for the kernel to allocate CPU cycles to a process. A process is said to be alive if it has an execution context. An alive process can perform actions, as opposite to a device driver. A device driver has some data fields and some methods, but the only way it can actually do something is when one of its method gets called from an execution context of a process or a kernel interrupt handler.

Pipeline

Every pipeline is a job, because every process in the pipeline should be manipulated (stopped, resumed, killed) simultaneously.

Threads

The operating system schedules the threads to run against physical (or virtual) processors.

Signals

Linux Signals

TTY

http://www.linusakesson.net/programming/tty/

Pseudo tty

With the first terminals, there was always a piece of hardware (display or serial port) attached to the device. With XWindows, telnet and ssh, there came a need for software pseudo devices to do the job of standing in for display hardware. These are the pseudo terminals, software that emulates terminal hardware, handling input and output in the same way a physical device would do.

Sockets

Unix domain sockets are bidirectional communication mechanisms that allow processes running within the same host operation system to exchange data. IP (network) sockets are bidirectional communication mechanisms allowing processes running on different hosts to exchange data over the network. Because of simplifying assumptions, UNIX sockets are faster and lighter, so they should be preferred over network sockets when we are sure the process are collocated. UNIX and network sockets share the API. They are subject to filesystem permissions. More details: https://en.wikipedia.org/wiki/Unix_domain_socket, https://en.wikipedia.org/wiki/Network_socket.

The /sys Filesystem

• https://en.wikipedia.org/wiki/Sysfs

cgroups

Linux cgroups

Namespaces

Linux Namespaces

File Descriptor

A file descriptor is a non-negative integer used internally by a process to identity and access a file and other input/output resource such as a pipe or a network socket. File descriptors are part of the POSIX application programming interface. Each process should expect to have three standard POSIX file descriptors, corresponding to the three standard streams:

• standard input (stdin), whose file descriptor is 0.
• standard output (stdout), whose file descriptor is 1.
• standard error (stderr), whose file descriptor is 2.

The file descriptor is an index into a per-process file descriptor table maintained by the kernel, that in turn indexes into a system-wide table of files opened by all processes, called the file table. This table records the mode with which the file or other resource has been opened: for reading, writing, appending, etc. It also indexes into a third table called the inode table that describes the actual underlying files. To perform input or output, the process passes the file descriptor to the kernel through a system call, and the kernel will access the file on behalf of the process. The process does not have direct access to the file or inode tables.

On Linux, the set of file descriptors open in a process can be accessed under the path /proc/<pid>/fd/.

Memory-Mapped File

lsof tells if a file opened by a process is memory mapped, by displaying "mem" in the FD column.

Peripheral Component Interconnect (PCI)

https://en.wikipedia.org/wiki/Conventional_PCI

USER_HZ

CPU statistics are expressed in ticks of 1/100h of a second, also called "user jiffies" There are USER_HZ "jiffies" per second, and on x86 systems, USER_HZ is 100. Historically, this mapped exactly to the number of scheduler "ticks" per second, but higher frequency scheduling and tickless kernels have made this number irrelevant.

Some documents express USER_HZ as 1/100th of a second.

For the actual value on the system, use sysconf(_SC_CLK_TCK) or execute:

getconf CLK_TCK