4.1: The Linux System - Vito Asta - Home PageLinux Operating System 4.1.3 The Linux Kernel •Version 0.01 (May 1991) had no networking, ran only on 80386 compatible Intel processors

Linux Operating System4.1.1

4.1: The Linux System�History �Design Principles�Kernel Modules�Process Management�Scheduling �Memory Management �File Systems�Input and Output �Interprocess Communication�Network Structure�Security


History

• Linux is a modern, free operating system based on UNIX standards.

• First developed as a small but selfcontained kernel in 1991 by Linus Torvalds, with the major design goal of UNIX compatibility.

• Its history has been one of collaboration by many users from all around the world, corresponding almost exclusively over the Internet.

• It has been designed to run efficiently and reliably on common PC hardware, but also runs on a variety of other platforms.

• The core Linux operating system kernel is entirely original, but it can run much existing free UNIX software, resulting in an entire UNIXcompatible operating system free from proprietary code.


The Linux Kernel

• Version 0.01 (May 1991) had no networking, ran only on 80386compatible Intel processors and on PC hardware, had extremely limited devicedrive support, and supported only the Minix file system.

• Linux 1.0 (March 1994) included these new features:– Support for UNIX’s standard TCP/IP networking protocols– BSDcompatible socket interface for networking

programming– Devicedriver support for running IP over an Ethernet– Enhanced file system– Support for a range of SCSI controllers for

highperformance disk access– Extra hardware support

• Version 1.2 (March 1995) was the final PConly Linux kernel.


Linux 2.0

• Released in June 1996, 2.0 added two major new capabilities:– Support for multiple architectures, including a fully 64bit

native Alpha port.– Support for multiprocessor architectures

• Other new features included:– Improved memorymanagement code– Improved TCP/IP performance– Support for internal kernel threads, for handling

dependencies between loadable modules, and for automatic loading of modules on demand.

– Standardized configuration interface

• Available for Motorola 68000series processors, Sun Sparc systems, and for PC and PowerMac systems.


Linux 2.4

• Version 2.2 was released in January 1999.

• Released in March 2000, v. 2.4 is the current stable version.

• Some important new features:– Support for many new filesystems, including ReiserFS, Ext3fs, Irix

efs, UDF standard (for DVDs), etc.– Improved scalability:

• Max. task limit is beyond 4000• completely rewritten CPU scheduling algorithm• Support for enterpriseclass hardware (e.g., RAM can be

addressed beyond 4 GB limit)• Very effective support for SMP machines, with many CPUs

• Available for even more processor platforms (including all the IBM machines, 3Com PalmPilot and Psion5, StrongARM, Intel IA64, etc.)

• New tasklet mechanism, for better handling of lowlevel interrupts

• Kernellevel Web daemon, kHTTPd, for better performance.


The Linux System

• Linux uses many tools developed as part of Berkeley’s BSD operating system, MIT’s X Window System, and the Free Software Foundation's GNU project.

• The main system libraries were started by the GNU project, with improvements provided by the Linux community.

• Linux networkingadministration tools were derived from 4.3BSD code; recent BSD derivatives such as Free BSD have borrowed code from Linux in return.

• The Linux system is maintained by a loose network of developers collaborating over the Internet, with a small number of public ftp sites acting as de facto standard repositories.


Linux Distributions

• Standard, precompiled sets of packages, or distributions, include the basic Linux system, system installation and management utilities, and readytoinstall packages of common UNIX tools.

• The first distributions managed these packages by simply providing a means of unpacking all the files into the appropriate places; modern distributions include advanced package management.

• Early distributions included SLS and Slackware. Red Hat and Debian are popular distributions from commercial and noncommercial sources, respectively. More recent distributions include SuSe and Mandrake.

• The RPM Package file format and manager tool permit compatibility among the various Linux distributions; RPM = RedHat Package Manager.


Linux Licensing

• The Linux kernel is distributed under the GNU General Public License (GPL), the terms of which are set out by the Free Software Foundation.

• Anyone using Linux, or creating their own derivative of Linux, may not make the derived product proprietary; software released under the GPL may not be redistributed as a binaryonly product.


Design Principles

• Linux is a multiuser, multitasking system with a full set of UNIXcompatible tools..

• Its file system adheres to traditional UNIX semantics, and it fully implements the standard UNIX networking model.

• Main design goals are speed, efficiency, and standardization.

• Linux is designed to be compliant with the relevant POSIX documents; at least two Linux distributions have achieved official POSIX certification.

• The Linux programming interface adheres to the SVR4 UNIX semantics, rather than to BSD behavior.


Kernel Source Code

• Implemented in C and assembler.

• Designed to be compiled with GNU C compiler, gcc, and GNU assembler.

– Uses some gccspecific language extensions: inline, asmlinkage, etc.

– Sometimes coded in dependence of the way gcc optimizes code.

– Portability is not a problem: gcc can generate code for dozens of CPUs.

• Major goal is speed, not elegance: heavy use of gotos (about one every 260 lines).


Kernel Code Idioms• Resource acquisition idiom, error variable idiom:

int f(void){

int err;resource *r1, *r2;

err = -ERR1; /* assume failure */r1 = get_resource1();if(!r1)

goto out; /* returns -ERR1 */err = -ERR2;r2 = get_resource2();if(!r2)

goto out1; /* returns -ERR2 *//* have both r1 and r2 */err = 0; /* no error *//* … function inner body; use both resources... */

out2:release_resource(r2);

out1:release_resource(r1);

out:return err;

}


Kernel Code Idioms

• Little use of #if, #ifdef in portability issues platformdependent code is encapsulated in functions or macros having more than one implementation.

• do { … } while(0) idiom:#define FREE1(p) if(p) free(p);

#define FREE2(p) if(p) { free(p); }

#define FREE3(p) { if(p) free(p); }

#define FREE4(p) do { if(p) free(p); }while 0 /* reduces macro to a single statement */

if(expr) FREEx(p); else printf(“…”); /* FREE4() is OK, the others give errors */


Kernel Code Idioms

• See also “Linux Kernel Coding Style”, in any Linux distribution, file ./Documentation/CodingStyle:

– “First off, I'd suggest printing out a copy of the GNU coding standards, and NOT read it. Burn them, it's a great symbolic gesture”. (Linus Torvalds)

– tabs are 8 characters– opening braces should go last on the line– naming (terse names, but descriptive for globals)– functions (“short and sweet”; max. 2 screenful long)– commenting (explain WHAT your code does, not HOW)

• Other thoughts from Linus Torvalds:“…message passing as the fundamental operation of the OS

is just an exercise in computer science masturbation. It may feel good, but you don’t actually get anything DONE”.


Kernel Source Directory Structure

• Kernel sources are in /usr/src/linux.• arch architecture specific kernel code. It has further subdirectories, one per

supported architecture (e.g. i386).• include contains most of the include files needed to build the kernel code.• init initialization code for the kernel a very good place to start looking at how the

kernel works. • mm memory management code; architecture specific memory management code

lives down in arch/*/mm/, e.g. arch/i386/mm/fault.c. • drivers device drivers; they are further subdivided into classes, e.g. block, char,

net, pci• ipc kernel’s interprocess communication code. • modules directory used to hold built modules.

• fs file system code; further subdivided into directories, one per supported file system, e.g. vfat, ext2.

• kernel main kernel code; architecture specific kernel code is in arch/*/kernel.

• net kernel's networking code. • lib kernel's library code; architecture specific library code can be found in arch/*/lib/.

• scripts scripts (for example awk and tk scripts) to be used when the kernel is configured.


Building the Kernel• When the user types 'make zImage' or 'make bzImage' the resulting bootable

kernel image is stored as arch/i386/boot/zImage or arch/i386/boot/bzImage respectively. Here is how the image is built:

– C and assembly source files are compiled into ELF relocatable object format (.o) and some of them are grouped logically into archives (.a) using ar(1)

– Using ld(1), the above .o and .a are linked into 'vmlinux' which is a statically linked, nonstripped ELF 32bit LSB 80386 executable file

– System.map is produced by 'nm vmlinux', irrelevant or uninteresting symbols are grepped out.

– Enter directory arch/i386/boot – Bootsector asm code bootsect.S is preprocessed either with or without

D__BIG_KERNEL__, depending on whether the target is bzImage or zImage, into bbootsect.s or bootsect.s respectively

– bbootsect.s is assembled and then converted into 'raw binary' form called bbootsect (or bootsect.s assembled and rawconverted into bootsect for zImage)

– Setup code setup.S (setup.S includes video.S) is preprocessed into bsetup.s for bzImage or setup.s for zImage. In the same way as the bootsector code, the difference is marked by D__BIG_KERNEL__ present for bzImage. The result is then converted into 'raw binary' form called bsetup


Building the Kernel (Cont.)

– Enter directory arch/i386/boot/compressed and convert /usr/src/linux/vmlinux to $tmppiggy (tmp filename) in raw binary format, removing .note and .comment ELF sections

– gzip 9 < $tmppiggy > $tmppiggy.gz

– Link $tmppiggy.gz into ELF relocatable (ld r) piggy.o

– Compile compression routines head.S and misc.c (still in arch/i386/boot/compressed directory) into ELF objects head.o and misc.o

– Link together head.o misc.o piggy.o into bvmlinux (or vmlinux for zImage, don't mistake this for /usr/src/linux/vmlinux!). Note the difference between Ttext 0x1000 used for vmlinux and Ttext 0x100000 for bvmlinux, i.e. for bzImage compression loader is highloaded

– Convert bvmlinux to 'raw binary' bvmlinux.out removing .note and .comment ELF sections

– Go back to arch/i386/boot directory and using the program tools/build cat together bbootsect + bsetup + compressed/bvmlinux.out into bzImage (delete extra 'b' above for zImage). This writes important variables like setup_sects and root_dev at the end of the bootsector. The size of the bootsector is always 512 bytes.


Components of a Linux System


Components of a Linux System (Cont.)

• Like most UNIX implementations, Linux is composed of three main bodies of code; the most important distinction is between the kernel and all other components.

• a) the kernel is responsible for maintaining the important abstractions of the operating system.

– Kernel code executes in kernel mode with full access to all the physical resources of the computer.

– All kernel code and data structures are kept in the same single address space (Monolithic organization).


Components of a Linux System (Cont.)

• b) the system libraries define a standard set of functions through which applications interact with the kernel, and which implement much of the operatingsystem functionality that does not need the full privileges of kernel code.

• c) the system utilities perform individual specialized management tasks; they include the daemon programs (program that start at boot time, and never exit; e.g. network servers, system message logger (syslogd), etc.)


Kernel Modules

• Kernel modules: sections of kernel code that can be compiled, loaded, and unloaded independent of the rest of the kernel.

• A kernel module may typically implement a device driver, a file system, or a networking protocol.

• Important licensing aspect: the module interface allows third parties to write and distribute, on their own terms, device drivers or file systems that could not be distributed under the GPL.

• Kernel modules allow a Linux system to be set up with a standard, minimal kernel, without any extra device drivers built in.

• Three components to Linux module support:– module management – driver registration– conflict resolution


Module Management• Module management: supports loading modules into memory and

letting them talk to the rest of the kernel.

• Module loading is split into two separate sections:– managing sections of module code in kernel memory– handling symbols that modules are allowed to reference

• Linux maintains a kernel symbol table (symbols explicitly exported by kernel sources); this constitutes a welldefined interface for a module to interact with kernel.

• The module loader (a system utility) first requests the reservation of a memory area where to load the module’s segments (text, data); then the unresolved symbols for module are matched with kernel table, and the kernel table is updated with new symbols from module.

• The module requestor (another system utility) manages loading kernelrequested, but currently unloaded, modules; it also regularly queries the kernel to see whether a dynamically loaded module is still in use, and will unload it when it is no longer actively needed.


Driver Registration

• Driver registration component: allows modules to tell the rest of the kernel that a new driver has become available.

• The kernel maintains dynamic tables of all known drivers, and provides a set of routines to allow drivers to be added to or removed from these tables at any time.

• Registration tables include the following items: – Device drivers– File systems, to be handled by the VFS (Virtual File

System see later) mechanism• real, local F.S. format (e.g. Minix, Ext2)• distributed F.S. (e.g. NFS)• pseudo F.S. (e.g. Proc)

– Network protocols• entire protocol stack (e.g. TCP/IP)• extra layer over existing stack (e.g. IP packet filtering)

– Binary formats• load and execute a new type of executable file


Conflict Resolution

• A mechanism that allows different device drivers to reserve hardware resources and to protect those resources from accidental use by another driver.

• The conflict resolution module aims to:– Prevent modules from clashing over access to hardware

resources– Prevent autoprobes from interfering with existing device

drivers– Resolve conflicts with multiple drivers trying to access the

same hardware (e.g., Printer driver with PLIP driver: they both use a parallel port device)


Process Management

• The central data structure is struct task_struct.

• UNIX process management separates the creation of processes and the running of a new program into two distinct operations.

– The fork system call creates a new process.– A new program is run after a call to execve.

• Under UNIX, a process encompasses all the information that the operating system must maintain to track the context of a single execution of a single program.

• Under Linux, process properties fall into three groups:– process identity– process environment– process context.


Process Identity

• Process Identity: PID, Credentials, Personality.

• Process ID (PID). The unique identifier for the process; used to specify processes to the operating system when an application makes a system call to signal, modify, or wait for another process.

• Credentials. Each process must have an associated user ID and one or more group IDs that determine the process’s rights to access system resources and files.

• Personality. Not traditionally found on UNIX systems, but under Linux each process has an associated personality identifier that can slightly modify the semantics of certain system calls.Used primarily by emulation libraries to request that system calls be compatible with certain specific flavors of UNIX.


Process Environment

• The process environment is inherited from the parent, and is composed of two nullterminated vectors (true for any Unix):

– The argument vector lists the commandline arguments used to invoke the running program; conventionally starts with the name of the program itself

– The environment vector is a list of “NAME=VALUE” pairs that associates named environment variables with arbitrary textual values.

• Passing environment variables among processes and inheriting variables by a process’s children are flexible means of passing information to components of the usermode system software.

• The environmentvariable mechanism provides a customization of the operating system that can be set on a perprocess basis, rather than being configured for the system as a whole.

• (N.B. – all this is true for any Unix system).


Process Context

• Process context: the (constantly changing) state of a running program at any point in time. It includes: scheduling context, accounting information, open file context, file system context, signalhandler table, virtual memory context.

• The scheduling context is the most important part of the process context; it is the information that the scheduler needs to suspend and restart the process. This includes the kernel stack for the process.

• The kernel maintains accounting information about the resources currently being consumed by each process, and the total resources consumed by the process in its lifetime so far.

• The open file context refers to the I/O channels currently open for a process; this is includes basically a set of pointers to the file table, i.e. an array of pointers to kernel file structures (struct file). When making file I/O system calls, processes refer to files by their index into this table (the file descriptor). The kernel file structures all belong to a systemwide table.

• (N.B. – basically true for any Unix system).


Process Context (Cont.)

• Whereas the open file context lists the existing open files, the filesystem context applies to requests to open new files. The current root and current (working) directories to be used for new file searches are stored here.

• The signalhandler table defines the routine in the process’s address space to be called when specific signals arrive.

• The virtualmemory context of a process describes the full contents of its private address space.

• (N.B. – all this is true for any Unix system).


Processes and Threads

• Linux uses the same internal representation for processes and threads (sometimes generally referred to as tasks); a thread is simply a new process that happens to share the same address space as its parent.

• A distinction is only made when a new thread is created by the clone system call.

– fork creates a new process with its own entirely new process context

– clone creates a new process with its own identity, but that is allowed to share the data structures of its parent

• a new process has always its own new identity and scheduling context

• the other subcontexts may be individually copied from parent or shared with it, depending on argument flags given to clone.


Processes and Threads (Cont.)

• Using clone gives an application finegrained control over exactly what is shared between two threads.

– sharing nothing is like a fork a new process, in classical UNIX context

– sharing everything (supplying all five flags to clone) creates a true traditional thread

– other combinations are possible, yielding some inbetween situations.

• Pthreads routines (defined by POSIX.1c) are implemented, in Linux, both at kernel level (with clone) and at user library level (see Module 1.5); each application can choose which implementation to use.


Processes and Threads (Cont.)

• #include <sched.h> int __clone(int (*fn) (void *), void *child_stack, int flags, void *arg);

– creates new process with controlled resource sharing– on child creation, (*fn)(arg) is called; when this function returns,

process exits, with code given by return value of function– child_stack is location of stack for child process (upper address of a

dedicated buffer)– flags has, in lower byte, number of signal to be sent to parent on

child exit; this value can be ORed with one or more of following values:

• CLONE_VM share memory space• CLONE_FS share filesystem info (root dir, curr. dir, umask)• CLONE_FILES share file descriptor table• CLONE_SIGHAND share table of signal handlers• CLONE_PID share PID (child gets same PID as parent).


Scheduling

• CPU scheduling: the job of allocating CPU time to different tasks within an operating system.

• While CPU scheduling is normally thought of as the running and interrupting of user processes, in Linux, scheduling also includes the running of the various kernel tasks.

• Running kernel tasks encompasses both tasks that are requested by a running process and tasks that execute internally on behalf of a device driver.


Kernel Synchronization

• A request for kernelmode execution can occur in two ways:– A running program may request an operating system

service, either explicitly via a system call, or implicitly, for example, when a page fault occurs.

– A device driver may deliver a hardware interrupt that causes the CPU to start executing a kerneldefined handler for that interrupt.

• Kernel synchronization requires a framework that will allow the kernel’s critical sections to run without interruption by another critical section.


Kernel Synchronization (Cont.)• Linux uses two techniques to protect critical sections:

1. Normal (non critical) kernel code is nonpreemptible– when a timer interrupt is received while a process is executing a kernel system service routine, the kernel’s need_resched flag is set so that the scheduler will run once the system call has completed and control is about to be returned to user mode.

– exceptions: kernel code will be preempted in case of:• an explicit call to the scheduler (e.g., going to sleep)• an interrupt• a page fault (may require I/O from disk, hence going to sleep)

2. The second technique applies to critical sections that occur in interrupt service routines.– By using the processor’s interrupt control hardware to disable interrupts during a critical section, the kernel guarantees that it can proceed without the risk of concurrent access of shared data structures.


Kernel Synchronization (Cont.)

• Problem: disabling interrupts implies performance penalties– enable/disable interrupt instructions are costly operations– all other interrupts are suspended for a while, and this gives

problems and lowers performance.

• To avoid such penalties, Linux’s kernel uses a synchronization architecture that allows long critical sections to run without having interrupts disabled for the critical section’s entire duration.

• Interrupt service routines are separated into a top half and a bottom half.

– The top half is a normal interrupt service routine, and runs with recursive interrupts disabled (only higherpriority interrupts can interrupt the routine). This part is always very short.

– The bottom half is run, with all interrupts enabled, by a miniature scheduler that ensures that bottom halves never interrupt themselves. This is the part that does most of the job.

– This architecture is completed by a mechanism for disabling selected bottom halves while executing normal, foreground kernel code.


Interrupt Protection Levels

• Each level may be interrupted by code running at a higher level, but will never be interrupted by code running at the same or a lower level.

• User processes can always be preempted by another process when a timesharing scheduling interrupt occurs.


Process Scheduling

• Linux uses three processscheduling algorithms:– One timesharing algorithm for fair preemptive scheduling

between multiple processes– Two realtime algorithms for tasks where absolute priorities are

more important than fairness

• A process’s scheduling class, or scheduling policy, defines which algorithm to apply. This is conformant with POSIX.1b (realtime extensions).

• Timesharing scheduling class: for timesharing processes, Linux uses a prioritized, creditbased algorithm.

– The crediting rule

factors in both the process’s history and its priority.– This crediting system automatically prioritizes interactive or I/O

bound processes.

credits :=credits

2priority


Process Scheduling (Cont.)

• Linux implements the FIFO and RR (roundrobin) realtime scheduling classes (see Module 5); in both cases, each process has a priority in addition to its scheduling class.

– The scheduler runs the process with the highest priority; for equalpriority processes, it runs the longestwaiting one

– FIFO processes continue to run until they either exit or block

– A RR process will be preempted after a while (when its time quantum expires) and moved to the end of the scheduling queue, so that roundrobin processes of equal priority automatically timeshare between themselves.

• N.B. this is soft realtime, not hard realtime: there is no guarantee on the time it will take for a realtime process to start or restart execution, once the scheduler has made its choice.


Symmetric Multiprocessing

• Linux 2.0 was the first stable Linux kernel to support SMP (simmetric multiprocessor) hardware; separate processes or threads can execute in parallel on separate processors. The first experimental kernel was 1.3.42, released in November 1995.

• To preserve the kernel’s nonpreemptible synchronization requirements, SMP imposed the restriction, via a single big kernel spinlock, that only one processor at a time may execute kernelmode code.

• From Linux 2.1, more than one processor at a time may execute kernelmode code; each processor acquires exclusive access to sections of kernel data via (multiple) kernel spinlocks.

• In Linux 2.4– The single kernel spinlock has almost totally disappeared from

the kernel.– All code for signal handling, interrupts, and some I/O routines use

multiple spinlocks to let multiple CPUs to execute kernelmode code simultaneously.


Symmetric Multiprocessing• There are 3 types of kernel spinlocks:

– basic spinlock (spin_lock(), spin_unlock())– readwrite spinlock (for readerswriters problem see Module 6) (read_lock(),

read_unlock(); write_lock(), write_unlock())– bigreader spinlock (like previous but optimized for readers, with penalty for

writers) (br_read_lock(), br_read_unlock(); br_write_lock(), br_write_unlock())

• Each one of them has 4 different variants, which may or may not disable interrupts:– plain (e.g. spin_lock(), spin_unlock()) – the interrupt state of current CPU is not

touched. To be used if interrupts are disabled, or if there’s no race with interrupt context

– irq (e.g. spin_lock_irq(), spin_unlock_irq()) – disables (on lock) and reenables (on unlock) interrupts on current CPU. To be used if interrupts are always enabled on entry in critical section

– irqsave/restore (e.g. spin_lock_irqsave(), spin_unlock_irqrestore()) – strongest form; disables interrups if not already done (on lock) and restores original interrupt state (on unlock) on current CPU. To be used when the interrupt state is not known.

– bh (e.g. spin_lock_bh(), spin_unlock_bh()) – intermediate form; interrupts (tophalves) are enabled, but bottomhalves are not.

• One cannot block while holding a spinlock.


Symmetric Multiprocessing (Cont.)

• Typical example code, in a device driver:

: spinlock_t my_lock = SPIN_LOCK_UNLOCKED;

my_ioctl() { unsigned long flags; spin_lock_irq(&my_lock, flags); /* (this is a macro; context saved in flags) */ /* critical section here */

... spin_unlock_irq(&my_lock, flags); }

my_irq_handler() { spin_lock(&lock); /* critical section here */

... spin_unlock(&lock); }

• First method is process (background) context; interrupts are surely enabled, so it must use spin_lock_irq(). Second method is interrupt context; interrupts are always disabled in an interrupt, so it may simply use spin_lock().


Memory Management

• Linux’s memory management can be divided in two parts:– physical memorymanagement system deals with

allocating and freeing pages, groups of pages, and small blocks of memory.

– additional mechanisms for handling virtual memory memory mapped into the address space of running processes.


Managing Physical Memory

• The page allocator allocates and frees all physical pages; it can allocate ranges of physicallycontiguous pages on request.

• The allocator uses a buddyheap algorithm to keep track of available physical pages.

– Each allocatable memory region is paired with an adjacent partner.

– Whenever two allocated partner regions are both freed up they are combined to form a larger region.

– If a small memory request cannot be satisfied by allocating an existing small free region, then a larger free region will be subdivided into two partners to satisfy the request.

• Linux implements linked lists of free regions for each permissible size (smaller size: 1 page, i.e. 4K).


Splitting of Memory in a Buddy Heap


Managing Physical Memory (Cont.)

• Memory allocations in the Linux kernel occur either statically (typically, device drivers or other kernel subsystems reserve a contiguous area of memory during system boot time) or dynamically (via the page allocator).

• Kernel functions usually handle memory resources via specialized subsystems, which all use the basic page allocator:

– kmalloc (like malloc(3), allocates full pages but can split them in smaller units)

– buffer cache (I/O cache for block devices: handling memory at the device level)

• struct buffer_head;– page cache (holds pages of files: handling memory at the

file level; used not only for block devices but also for network devices, e.g. for NFS remote filesystems)

• typedef struct page mem_map_t;– virtual memory system (VM system)

• struct vm_area_struct;


Managing Physical Memory (Cont.)

• The buffer cache, page cache and VM system interact with each other:

– Reading a file’s page in page cache implies a temporary usage of the buffer cache.

– With memorymapped files, a page in the page cache is also addressed by the VM system (the file’s contents are entirely mapped in one or more process’ address space).

– As always, reference counts are maintained in the relevant data structures for each physical page pointed to by one or more subsystems.


Virtual Memory

• The VM system maintains the address space visible to each process: It creates pages of virtual memory on demand, and manages the loading of those pages from disk or their swapping back out to disk as required.

• The VM manager maintains two separate views of a process’s address space:

– A logical view, reflecting informations concerning the layout of the process address space. This is described by a struct mm_struct. The address space consists of a set of nonoverlapping regions, each representing a continuous, pagealigned subset of the address space. Each region is described by a struct vm_area_struct, also known as VMA (Virtual Memory Area).

– A physical view, of each address space which is stored in the hardware page tables for the process. Each physical page is described by a struct page, also known as a mem_map_t


Virtual Memory (Cont.)

• The mm_struct, in /usr/include/linux/sched.h:/* each task_struct points to a mm_struct; this one points to a list or tree of VMAs associated to that process */

struct mm_struct {struct vm_area_struct *mmap; /* list of VMAs */struct vm_area_struct *mmap_avl; /* tree of VMAs */struct vm_area_struct *mmap_cache; /* last find_vma result */pgd_t * pgd; /* page directory entry */atomic_t count;int map_count; /* number of VMAs */struct semaphore mmap_sem;unsigned long context;unsigned long start_code, end_code, start_data, end_data;unsigned long start_brk, brk, start_stack;unsigned long arg_start, arg_end, env_start, env_end;unsigned long rss, total_vm, locked_vm;unsigned long def_flags;unsigned long cpu_vm_mask;unsigned long swap_cnt; /* number of pages to swap on next pass */unsigned long swap_address;/* * This is an architecture-specific pointer: the portable * part of Linux does not know about any segments. */void * segments;

};



• The vm_area_struct, in /usr/include/linux/mm.h:/* This struct defines a VMA memory area. There is one of these per VM-area/task. A VM area (VMA) is

any part of the process virtual memory space that has a special rule for the page-fault handlers, ie a shared library, the executable area (text segment) etc. */struct vm_area_struct {

struct mm_struct * vm_mm; /* VM area parameters */unsigned long vm_start;unsigned long vm_end;

/* linked list of VM areas per task, sorted by address */struct vm_area_struct *vm_next;pgprot_t vm_page_prot;unsigned short vm_flags;

/* AVL tree of VM areas per task, sorted by address */short vm_avl_height;struct vm_area_struct * vm_avl_left;struct vm_area_struct * vm_avl_right;

/* For areas with inode, the list inode->i_mmap, for shm areas, the list of attaches, otherwise unused */struct vm_area_struct *vm_next_share;struct vm_area_struct **vm_pprev_share;struct vm_operations_struct * vm_ops;unsigned long vm_offset;struct file * vm_file;unsigned long vm_pte; /* shared mem */

};



• Virtual memory regions are characterized by:– The backing store, which describes from where the pages for

a region come; regions are usually backed by a file or by nothing (demandzero memory read as all 0’s)

– The region’s reaction to writes (page sharing, for global view of the region, or copyonwrite, for local private view).

• A region backed by a file is a window onto that file:– page table entry is filled with page address in kernel’s page

cache– same physical page used by page cache and by process’s

page tables, so changes are visible anywhere– such regions can be mapped by any number of processes

(reference count handled)



• The kernel creates a new virtual address space1. When a process runs a new program with the exec

system call2. Upon creation of a new process by the fork system call

• On executing a new program, the process is given a new, completely empty virtualaddress space; the programloading routines populate the address space with virtualmemory regions.



• Creating a new process with fork involves creating a complete copy of the existing process’s virtual address space.

– The kernel copies the parent process’s VMA descriptors, then creates a new set of page tables for the child.

– The parent’s page tables are copied directly into the child’s, with the reference count of each page covered being incremented.

– After the fork, the parent and child share the same physical pages of memory in their address spaces.

– A private region (typically, from the data segment) is set as readonly and marked as copyonwrite: first attempt to write will trap to the kernel, which makes a brand new copy for the process, set to read/write this time; pointers and reference counts are updated; the modification will then succeed, transparently to the process.



• The VM paging system relocates pages of memory from physical memory out to disk when the memory is needed for something else.

• The VM paging system can be divided into two sections:– The pageoutpolicy algorithm decides which pages to

write out to disk, and when.– The paging mechanism actually carries out the transfer,

and pages data back into physical memory as needed.

• A modified secondchance substitution algorithm is used (see Module 1.8):

– age valuing mechanism– pages are selected based on LFU policy – LFU pageout

algorithm

• Blocks are allocated in swap space with bitmap of used blocks; nextfit algorithm is used, to try to write out pages to continuous runs of disk blocks (for better performance).



• The Linux kernel reserves a constant, architecturedependent region of the virtual address space of every process for its own internal use.

• This kernel virtualmemory area contains two regions:– A static area that contains page table references to every

available physical page of memory in the system, so that there is a simple translation from physical to virtual addresses when running kernel code.

– The reminder of the reserved section is not reserved for any specific purpose; its pagetable entries can be modified to point to any other areas of memory.


Executing and Loading User Programs

• Linux maintains a table of functions for loading programs; it gives each function the opportunity to try loading the given file when an exec system call is made.

• The registration of multiple loader routines allows Linux to support both the ELF (Executable and Linking Format) and a.out (Assembler OUTput format) binary formats; other nonnative formats are also supported:

– JAVA files– script files #! notation (shell, PERL, etc.)– miscellaneous formats, configurable at run time, based on magic

numbers or file suffix.

• Initially, binaryfile pages are mapped into virtual memory; only when a program tries to access a given page will a page fault result in that page being loaded into physical memory.

• An ELFformat binary file consists of a header followed by several pagealigned sections; the ELF loader works by reading the header and mapping the sections of the file into separate regions of virtual memory.


Memory Layout for ELF Programs

brk


Static and Dynamic Linking

• A program whose necessary library functions are embedded directly in the program’s executable binary file is statically linked to its libraries.

• The main disadvantage of static linkage is that every program generated must contain copies of exactly the same common system library functions.

• Dynamic linking is more efficient in terms of both physical memory and diskspace usage because it loads the system libraries into memory only once.

• Dynamic libraries are compiled into PositionIndependent Code (PIC), so they can be mapped to any address; at runtime, they are mapped into dedicated regions.


File Systems• To the user, Linux’s file system appears as a hierarchical

directory tree obeying UNIX semantics.

• Internally, the kernel hides implementation details and manages the multiple different file systems and file types via an abstraction layer, that is, the virtual file system (VFS).

• This way, many kinds of file systems are supported:– foreign: e.g. msdos, vfat, iso9660 (cdrom)– Unix variants: e.g. sysv, xenix– pseudof.s.: e.g. proc, pipefs

as well as file types, each one with permitted operations:– regular– directory– special character, block– FIFO– socket– etc.


File Systems

• The Linux VFS is designed around objectoriented principles and is composed of two components:

– A set of definitions that define what a file object is allowed to look like

• The inodeobject and the fileobject structures represent individual files: struct inode, struct file

• the file systemobject represents an entire file system: struct file_system_type

– A layer of software (methods, implemented as a set of pointers to functions) to manipulate those objects.

• An inodeobject represents a file as a whole; a fileobject represents a point of access to the data in the file.

• Fileobjects typically belong to a single process; inodeobjects do not.

• All cached data for a file are linked into a list in the inodeobject.

• Directory operations are defined in the inodeobject, rather than in the fileobject (directory system calls do not require that the file be opened).


The Linux Ext2fs File System

• Ext2fs uses a mechanism similar to that of BSD Fast File System (ffs) for locating data blocks belonging to a specific file.

• The main differences between ext2fs and ffs concern their disk allocation policies.

– In ffs, the disk is allocated to files in blocks of 8Kb, with blocks being subdivided into fragments of 1Kb to store small files or partially filled blocks at the end of a file.

– Ext2fs does not use fragments; it performs its allocations in smaller units. The default block size on ext2fs is 1Kb, although 2Kb and 4Kb blocks are also supported.

• Ffs cylinder groups correspond in ext2fs to block groups– modern drive technology allocate sectors in different

densities, depending on distance from disk center; hence, fixedsize cylinder groups do not correspond to disk’s geometry.


The Linux Ext2fs File System (Cont.)

• On file allocation, must first select block group– data blocks: same as where inode is allocated– inodes:

• nondirectory files: same as parent directory• directory files: they are dispersed among block groups

• Ext2fs uses allocation policies designed to place logically adjacent blocks of a file into physically adjacent blocks on disk, so that it can submit an I/O request for several disk blocks as a single operation.

– Maintains bitmap of free blocks in a block group– When allocating first block of a file, starts searching from

beginning of block group– when extending a file, starts from last block allocated to it– first searches for a free byte (8 consecutive blocks), then

goes backward; if it fails, searches for a free bit– wants to find 8 free blocks, to preallocate.


Ext2fs BlockAllocation Policies


The Linux Proc File System

• The proc file system does not store data, rather, its contents are computed on demand according to user file I/O requests.

• proc must implement a directory structure, and the file contents within; it must then define a unique and persistent inode number for each directory and files it contains.

– It uses this inode number to identify just what operation is required when a user tries to read from a particular file inode or perform a lookup in a particular directory inode.

– When data is read from one of these files, proc collects the appropriate information, formats it into text form and places it into the requesting process’s read buffer.


Input and Output

• The Linux deviceoriented file system accesses disk storage through two caches:

– Data is cached in the page cache, which is unified with the virtual memory system

– Metadata is cached in the buffer cache, a separate cache indexed by the physical disk block.

• Linux splits all devices into three classes:– block devices allow random access to completely

independent, fixed size blocks of data– character devices include most other devices; they don’t

need to support the functionality of regular files.– network devices are interfaced via the kernel’s

networking subsystem


Devicedriver Block Structure


Block Devices

• Provide the main interface to all disk devices in a system.

• The block buffer cache serves two main purposes:– it acts as a pool of buffers for active I/O– it serves as a cache for completed I/O

• Main structure is struct buffer_head; identified by a 3tuple:– device identity (MDN+mnd) of disk– start block number– buffer size (which is variable)

• The I/O request manager manages the reading and writing of buffer contents to and from a block device driver.

• Mechanism is similar, although different, to classical UNIX cache.


Character Devices

• A device driver which does not offer random access to fixed blocks of data.

• A character device driver must register a set of functions which implement the driver’s various file I/O operations.

• The kernel performs almost no preprocessing of a read or write request to a character device, but simply passes on the request to the device.

• The main exception to this rule is the special subset of character device drivers which implement terminal devices, for which the kernel maintains a standard interface; this is done through the struct tty_struct, analogous the the struct tty of classical Unix.


Interprocess Communication

• Like UNIX, Linux informs processes that an event has occurred via signals.

• There is a limited number of signals, and they cannot carry information: only the fact that a signal occurred is available to a process.

• The Linux kernel does not use signals to communicate with processes which are running in kernel mode, rather, communication within the kernel is accomplished via scheduling states and wait_queue structures:

struct __wait_queue wait_queue_t;

• Moreover, a semaphore mechanism is also included in the kernel, which is based in turn on wait_queue mechanism.


Wait Queues

static DECLARE_WAIT_QUEUE_HEAD(rtc_wait);

void rtc_interrupt(int irq, void *dev_id, struct pt_regs *regs)

{

spin_lock(&rtc_lock);

rtc_irq_data = CMOS_READ(RTC_INTR_FLAGS);

spin_unlock(&rtc_lock);

wake_up_interruptible(&rtc_wait);

}


Wait Queues (Cont.)ssize_t rtc_read(struct file file, char *buf, size_t count, loff_t *ppos)

{

DECLARE_WAITQUEUE(wait, current);

unsigned long data;

ssize_t retval;

add_wait_queue(&rtc_wait, &wait);

current->state = TASK_INTERRUPTIBLE;

do {

spin_lock_irq(&rtc_lock);

data = rtc_irq_data;

rtc_irq_data = 0;

spin_unlock_irq(&rtc_lock);

if (data != 0)

break;


Wait Queues (Cont.)if (file->f_flags & O_NONBLOCK) {

retval = -EAGAIN;

goto out;

}

if (signal_pending(current)) {

retval = -ERESTARTSYS;

goto out;

}

schedule();

} while(1);

retval = put_user(data, (unsigned long *)buf);

if (!retval)

retval = sizeof(unsigned long);

out:

current->state = TASK_RUNNING;

remove_wait_queue(&rtc_wait, &wait);

return retval;

}


Network Structure

• Networking is a key area of functionality for Linux.– It supports the standard Internet protocols for UNIX to

UNIX communications.– It also implements protocols native to nonUNIX operating

systems, in particular, protocols used on PC networks, such as Appletalk and IPX.

• Internally, networking in the Linux kernel is implemented by three layers of software:

– The socket interface (see Disp_P1_09)– Protocol drivers– Network device drivers


Network Structure (Cont.)

• The most important set of protocols in the Linux networking system is the Internet protocol suite (TCP/IP).

– IP implements routing between different hosts anywhere on the network.

– On top of the routing protocol are built the UDP, TCP and ICMP protocols.


Security

• Linux setuid mechanism: Linux augments the standard UNIX setuid mechanism in two ways:

– It implements the POSIX specification’s saved userid mechanism, which allows a process to repeatedly drop and reacquire its effective uid.

– It has added a process characteristic that grants just a subset of the rights of the effective uid.

• Linux provides another mechanism that allows a client to selectively pass access to a single file to some server process without granting it any other privileges.

Documents

4.1: The Linux System - Vito Asta - Home PageLinux Operating System 4.1.3 The Linux Kernel •Version 0.01 (May 1991) had no networking, ran only on 80386 compatible Intel processors