This presentation is devoted to the internal structure of the Linux operating system with a primary focus on the kernel, processes, and threads. Its goal is to provide students with a deeper understanding of how Linux manages execution, resources, and interactions between user programs and hardware at the lowest system level. The lecture begins with an overview of the Linux kernel structure, describing its role as the core component of the operating system. Key concepts such as block devices, virtual terminals (TTY, VT100), input/output handling, static and dynamic configuration, file systems (ext4, ZFS, and others), and the I/O scheduler are introduced. Special attention is given to how the kernel optimizes disk access and manages different types of devices. A major part of the presentation is dedicated to processes in Linux. A process is described as a combination of executable code, system information, and a control terminal. The lecture explains how processes are created using the fork() system call, which creates a child process as a logical copy of the parent while maintaining separate private memory spaces. Process identifiers (PIDs) are introduced as the primary mechanism for distinguishing processes, along with system calls such as getpid(). Interprocess communication (IPC) mechanisms are discussed, including pipes and POSIX signals. Signals are presented as software interrupts that temporarily suspend normal execution and transfer control to a signal handler. The concept of process groups is explained, clarifying which processes are allowed to send signals to each other. Special process states, such as zombie processes, are examined to illustrate what happens when a child process terminates before its parent collects its exit status using waitpid(). The lecture then explores how processes and threads are implemented internally in Linux. It explains the transition from user mode to kernel mode during a system call, which is handled as an emulated interrupt. Linux represents processes internally as tasks, stored in task_struct data structures and organized in a bidirectional list. The contents of the process descriptor are analyzed in detail, including scheduling parameters, memory layout, signal handling information, CPU register state, system call context, file descriptor tables, credentials, kernel stack, and process identifiers. Finally, the presentation addresses threads in Linux and their historical development. It explains the challenges of introducing multithreading into Unix systems and the role of the clone() system call, which unifies the implementation of processes and threads. The relationship between PID and TID is clarified, showing how Linux maintains compatibility with POSIX while allowing efficient multithreaded execution. Overall, this presentation provides a solid theoretical foundation for understanding Linux process management and kernel internals, preparing students for advanced studies in operating systems.

1. 1
Operating system Linux
Lecture 3

2. Kernel Structure
Search and random access allowed
only for block devices
tty – virtual terminal VT100
Character input either continuously,
or after clicking Enter
Static and dynamic settings
core components
There are many file systems: ext4, ZFS, …
I / O Scheduler
optimizes head movement for
HDD, or uses other strategies

3. Processes in Linux
• Process = System information + executable code + control terminal
• DEMONS!!! 1111
cron, systemd, nginx …
• Parent's address the process (parent process) ->
challenge fork -> child process (child process)
• fork creates an exact copy of the original process (not copying memory)
• The parent and child processes have their own (private) memory images
• Open files, registers, etc. are used by parent and child processes together
• To distinguish between processes the PID (Process) is used IDentifier —
process id

4. Processes in Linux
If the process wants to know its own PID, it can make a system call getpid
Processes communicate with each other using pipes and using signals (software interrupt). When it arrives, the
main thread of execution is suspended and control is passed to the signal handler.
A process can only send signals to members of its own process group (process group), consisting of its direct
parent( and other ancestors), siblings, and children (and other descendants)
https://github.com/torvalds/linux/blob/master/kernel/fork.c

5. POSIX signals

6. Command shell
minimum example
If the process has already ended, and the parent process is not waiting for this
event, then the child process is transferred to the so-called state zombies
(zombie state) "the living dead , that is, suspended. When the parent process
finally accesses the library procedure waitpid, the child process terminates.
In the most general case, a system call has exec three
parameters: executable name a pointer to an array of arguments,
and a pointer to an array of environment strings.

7. Process-specific system calls
Is the sender being blocked
or it gets control back immediately

8. Implementing processes and threads in Linux
• Each process has a user part in which the
user's program runs. However, when one
of the threads makes a system call, what
happens is emulated interrupt with
switching to kernel mode. After that, the
thread starts working in in the context of
the kernel with a different memory card
and full access to all machine resources.
• The Linux kernel internally represents
processes as tasks (tasks) using task
structures task_struct.
• The structure stores process handles
The kernel organizes everything processes in a bidirectional list of task
structures

9. Process handle
• Planning parameters. Process priority, spent over the last time the period taken into
account is the processor time, the amount of time spent in this mode waiting time. All
this information is used to select the process that will be executed next.
• Memory Image. Pointers to segments: text, data, and stack, or to tables paged paged.
If a text segment is shared, the text pointer points to a shared text table.
• Signals. Masks that indicate which signals are ignored, which are intercepted, which
are temporarily blocked, and which are in the process of being delivered.
• Machine registers. When an emulated interrupt occurs in the kernel, then machine
registers (including floating-point registers) are stored here.
• System Call Status. Information about the current system call (including parameters
and results).

10. Process handle
• File Descriptor Table. When a system call is made that uses file
descriptor, then the file descriptor is used as an index in this table to
find the corresponding data structure for this file (i-node).
• Credentials. Pointer to the table that tracks the used data. process user
and system CPU time. Some systems they also store here the maximum
values of the processor time that a process can use, the maximum size
of its stack, and the number of page blocks., which it can use, and so on.
• Kernel Stack. A fixed stack to be used by the part of the process that it
runs in kernel mode.
• Various. Current state of the process, events expected by the process (if
any), time until the alarm interval expires, PID of the process, PID of the
parent process, user and group IDs.

11. Command
Execution Steps
ls entered in
the shell

12. 12
Threads in Linux
• Initially in UNIX there were no streams
• The implementation of streams is fraught with many difficulties: when we forking it process,
what to do with threads: copy everything, do not copy at all, and if one thread is blocked by
input or output, and if several threads are working with it, and if no new threads are created,
then what to do with mutexes, what to do with file input and output, to whom and how to
send signals.
• Historically, processes were resource containers, and threads were units of execution.
• Only in 2000 in Linux a system call appeared clone, which combined processes and threads
and now there are almost no differences between them.
• But this implementation is no longer compatible with POSIX
• For the flow for compatibility remains PID (for both single-threaded and multi-threaded
processes), for threads it is used TID.
• When the call is made clone used to create a new process (which is nothing doesn't share it
with its creator), the PID is set to a new value, otherwise, the task gets a new TID, but inherits
the PID. So everything is the process threads will get the same PID as the first process thread.