Everything Penguin

Focusing on Linux-based Operating Systems
htDig Search:

Operating Systems
  • /pub/OS/Linux

  • Storage
  • File Systems
  • HPC
  • /pub/Storage

  • Networking
  • /pub/Networking

  • Network Services
  • /pub/NetworkServices

  • Security
  • /pub/Security
  • Keytool/OpenSSL

  • Clustering
  • HA
  • DRM

  • Development
  • Design
  • C/C++
  • Java
  • Perl
  • Python
  • Shell
  • Web / J2EE

  • Not Linux ?
  • BSD
  • HP-UX
  • Mac
  • Solaris
  • VM
  • Windows
  • /pub/OS

  • Other
  • /pub
  • /pub/3rdParty
  •  Parent Directory

    CPU Operation (Kernel & User) & System Calls
    Brett Lee
    =============================================================================
    
    To discuss modes of operation, we'll need to cover the following:
    
    CPU Modes
    System Calls
    Mode Switch vs. Context Switch
    
    
    * CPU Modes
    *****************
    
    Processors are capable of operating at different levels of privledge - it's up
    to each operating system how they want to utilize the levels.  Typically, there
    exists one "real" mode and at least one "protected" mode, with the protected
    mode possibly simulating a "ring" of escalating privledges.  A couple examples
    of these processors are the Motorola 68000 (containing two modes) and the Intel
    processors (containing four).  Intel refers to these modes as Rings, with Ring
    0 being the most "real." Although Unix may be executing on a CPU with four
    different modes, the Unix operating system creates only two modes, kernel and
    user.
    
    The kernel, the core of the operating system, contains the routines necesary
    for multiple applications to safely access hardware devices, memory, and
    filesystems without stepping all over each other.  When the processor executes
    in kernel mode, it is executing with a full set of privledges and access.
    Applications, on the other hand, are not trusted very much and thus execute in
    user mode.  Applications can, by means of system calls, request the kernel to
    perform the critical task of accessing the hardware.  But they cannot do it
    themselves.  This seperation provides a measure of protection for the system,
    as the kernel can enforce guidelines into what commands execute and thus
    severely restrict dangerous operations to "valid" code.
    
    To repeat, applications are not allowed to cross the addressing space into
    kernel mode, so to attempt risky operations (like interacting with the
    hardware) they must go through the kernel.
    
    
    
    Below is an example from:
    
      http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-3.html
    
    
    
                          
                   |          Applications           /|\
                   |         ______________           |
                   |         | User Mode  |           |  
                   |         ______________           | 
                   |               |                  |  
    Implementation |        _______ _______           |   Abstraction
        Detail     |        | Kernel Mode |           |
                   |        _______________           |
                   |               |                  |
                   |               |                  | 
                   |               |                  |
                  \|/          Hardware               |
    
    
    
    More info about this and Kernel Mode Linux can be found here:
    
      http://www.linuxjournal.com/article/6516
    
    
    
    
    
    
    * System calls
    *********************
    
    Linux is designed in such a way that to execute risky operations, the execution
    must occur in "kernel mode" accomplished by the use of "system calls."  In the
    Linux kernel, the system call execution specifics (sysenter/sysexit) have
    changed from 2.4 to 2.6 to utilize newer hardware which speeds up the process,
    however the general approach of using system calls has not changed.
    
    
    
    In short, a system call is the interface between userland and the kernel
    routines.  The kernel provides a system call, and the libraries (e.g. glibc)
    provide a wrapper (often with the same name as the system call) that developers
    use to access the system call.  When that happens, the kernel:
    
     a) switches the processor to Kernel Mode, and
     b) safely execute the instruction using routines in the kernel. 
    
    
    
    Here is another example, from:
    
        http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-3.html
    
    
    
                                     |                |
                             ------->| System Call i  | (Accessing Devices)
    |                |       |       |  [sys_read()]  |
    | ...            |       |       |                |
    | system_call(i) |--------       |                |
    |   [read()]     |               |                |
    | ...            |               |                |
    | system_call(j) |--------       |                |  
    |   [get_pid()]  |       |       |                |
    | ...            |       ------->| System Call j  | (Accessing kernel data structures)
    |                |               |  [sys_getpid()]|
                                     |                | 
    
        USER MODE                        KERNEL MODE
    
    
    As you can see, the User Mode System Calls are the interface to Kernel routines.
    Note that the Kernel routines (currently) begin with sys_*.  Older UNIX's may
    have began with "_*".
    
    Here are a few more examples:
    
    System call		: Corresponding kernel routine
    =-=-=-=-=-=-		 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
    
    time			: sys_time
    stime			: sys_stime
    gettimeofday		: sys_gettimeofday
    settimeofday		: sys_settimeofday
    adjtimex		: sys_adjtimex
    
    As of this writing, the syscalls are listed in:
    
      /usr/src/kernels/<version>/include/asm/unistd.h
    
    
    
    
    * Mode Switch vs. Context Switch
    **********************************
    
    As discussed above, the CPU has two modes - User and Kernel.  When an 
    application executing in User mode executes a system call, the CPU switches to
    Kernel mode and executes the instructions.  This switch in CPU state is called
    a mode switch, and the CPU now has more "power" (access to all the memory
    locations and other system resources).  The mode switch does not change the
    instructions that are executing, it simply changes its mode of execution.
    
    By contrast, a context switch DOES change the instructions that are executing.
    A context switch is the function of a multitasking operating system, and
    allows the instructions from one process or thread to be replaced by another
    set of instructions.  This typically involve moving the current state
    (switchframe) from the CPU's registers, replacing it with another switchframe.
    In the switchframe is a program counter that indicates the location where to
    restart begin execution, thus the "context" is the combination of the registers
    plus the program counter (a specialized register).
    
    In closing, its interesting (and obvious once you think about it) that a
    context switch can only occur in kernel mode.  Thus, every context switch
    involves a mode switch also.  Mode switches are relatively slow events, so
    system calls should be avoided whereever possible.  But, context switches
    are hard (impossible) to avoid.  Clearly a mode switch is not as CPU intensive
    as a context switch, but with many context switches each second, the net effect
    of these two really can chew up those nanoseconds of CPU time.
    
    For an idea of how many context switches actually happen, grab DTrace and
    take a look.  Hopefully that nice tool will be available for Linux soon.
    
    
    
    
    
    
    * The rest is up to you -
    ******************************
    
      System Calls:
      man 2 intro
    
      Implementing System Calls:
      http://www.linuxjournal.com/article/3326
    
      Kernel Programming:
      http://www.linuxhq.com/lkprogram.html
    
      Secure Programming for Linux and Unix HOWTO:
      http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html
    
      Lots of high level info:
      http://www.linux.com/base/ldp/howto/HOWTO-INDEX/programming.html
    
    
    

    Other Sites

    RFC's
  • FAQ's
  • IETF
  • RFC Sourcebook

  • Linux
  • Linux - Intro
  • Linux Kernel
  • Linux Kernel (LKML)
  • Bash - Intro
  • Bash - Advanced
  • Command Line
  • System Administration
  • Network Administration
  • Man Pages (& more)
  • More Guides
  • Red Hat Manuals
  • HOWTO's

  • Reference/Tutorials
  • C++ @ cppreference
  • C++ @ cplusplus
  • CSS @ echoecho
  • DNS @ Zytrax
  • HTML @ W3 Schools
  • Java @ Sun
  • LDAP @ Zytrax
  • Linux @ YoLinux
  • MySQL
  • NetFilter
  • Network Protocols
  • OpenLDAP
  • Quagga
  • Samba
  • Unix Programming



  • This site contains many of my notes from research into different aspects of the Linux kernel as well as some of the software provided by GNU and others. Thouugh these notes are not fully comprehensive or even completetly accurate, they are part of my on-going attempt to better understand this complex field. And, they are your to use.

    Should you wish to report any errors or suggestions, please let me know.

    Should you wish to make a donation for anything you may have learned here, please direct that donation to the ASPCA, with my sincere thanks.

    Brett Lee
    Everything Penguin

    The code for this site, which is just a few CGI scripts, may be found on GitHub (https://github.com/userbrett/cgindex).

    For both data encryption and password protection, try Personal Data Security (https://www.trustpds.com).


    "We left all that stuff out. If there's an error, we have this routine called 'panic', and when its called, the machine crashes, and you holler down the hall, 'Hey, reboot it.'"

        - Dennis Ritchie on Unix (vs Multics)


    Google
    [ Powered by Red Hat Linux ] [ Powered by Apache Server] [ Powered by MySQL ]

    [ Statistics by AWStats ]