System Service

Objectives

1. Understand some of the system program level services provided by an os.
2. Understand the linking/loading process
3. Understand why applications are not portable across operating systems.

Notes

• This is section 2.4
• They provide a list of services and examples of how they are provided
  • File management
    • ls, mkdir, rm
    • These employ calls such as
      • opendir, readdir
      • mkdir
      • unlink
    • Status information
      • ps, uptime, top, ...
    • File modification
      • vi, emacs, ...
      • ed, sed, grep
    • Programming support
      • compilers
      • valgrind, make, gdb, ...
    • Program loading and execution
      • ld (is a linker)
      • It links object files together and builds an executable.
      • This is normally invoked by gcc,
      • But you can run it yourself (assembly)
    • Communications
      • ssh, sftp
    • Background services
      • Job control in the shell
      • cron
      • at
• Linkers and loaders
  • This is 2.5
  • A compiler produces object files.
    • machine code
    • metadata for linking with
      • Other object files.
      • Libraries (.a, .so)
  • The linker (ld as above)
    • Combines these into an executable.
  • The loader
    • In linux this is done with the exec family
    • Loads the executable into memory
    • And performs any other tasks
      • Validation (is this user allowed to run this program)
      • Setting up the environment and copying command line arguments
      • Initializing registers
      • Jumping to the entry point of the program.
      • Setting up a new stack, heap, data segments
    • see myexec.cpp
    • see man 3 exec
• Why are applications os specific?
  • The executable are in different formats
    • Metadata is different in each os.
    • The binary code is the same (sort of)
      • Heap, stack, data, ... segments are in different locations.
    • System calls will vary
      • Interrupt vectors may be different.
    • Libraries may be in different formats, and function differently
    • Linux is called elf by the way
  • Interpreted apps are better
    • But again, system calls will be an issue.
    • Some OS features will not be available.
  • There is no agreement, or even a desire to have portable apps however.
• ABI : Application Binary Interface
  • A good introduction
  • A good reference
  • An ABI is to binaries what an API is to programs.
  • It assures that when the kernel changes, the binaries will continue to work.
  • And that binaries moved across different instances of an os will still work.
    • The kernel is constantly updated, look at https://kernel.org
    • Look at dnf list installed kernel
    • Look at uname -a or uname -r
  • When I reboot, I don't have to recompile everything.