CSOPESY_OS_structure

RAW FILE

This note has not been edited yet. Content may be subject to change.

original file

Operating System Structure

  • an operating system is made up of various structures and components
  • services provided by the OS, the interfaces it presents to users and applications, and the design principles that guide its implementation
  • also look at how the OS is build, booted, and debugged

_attachments/Pasted image 20250908130245.png

  • how the operating system "looks like"
  • there's another layer JUST for system calls

OS Services: User Services

  • User Interface (UI)
    • provides a way for users to interact with the system
    • could be in the form of command-line interface (CLI), graphical user interface (GUI) or touch-screen interface
  • Program Execution
    • loads a program into memory, runs it, and handles termination (normal or abnormal)
    • the instruction of that memory will be run by the CPU
    • normal termination: program voluntarily exits gracefully
    • abnormal termination: for some reason, bigla lang nag exit
  • I/O operations
    • manages I/O to files and devices (special mention of files)
    • users cannot control devices directly for protection (it's possible that a device can be accessed by 2+ applications/processes at a time, so the OS has to do something so that they don't conflict)
  • File-System Manipulation
    • programs can create, delete, read, write, and manipulate files and directories
    • file permissions management to allow/deny access to files or directories based on file ownership (different from file system management)
    • the OS or process could CRUD whether its a command or another application trying to manipulate files
    • as a user on the OS, if you go to properties of a file, you have certain permissions to modify certain types of files (.iso, etc.)
    • Computer Management > Local Users > Groups. groups may have certain file permissions including a folder or directory
    • some operating systems have no file permissions
    • _attachments/Pasted image 20250908131238.png
    • rw-r is OS
    • rwx is user
    • the last three is for everyone else
    • you don't have to memorize this apparently
  • Communications
    • enables processes to exchange information
    • normally via shared memory or message passing technique
    • allows processes to talk to another process, done by shared memory
  • Error Detection
    • the OS constantly checks for and handles errors in hardware, I/O devices, and user programs

OS Services: Services for System Efficiency

the OS does the resource allocation so it manages the CPU cycles, memory, etc.

  • Resource Allocation
    • allocates and manages resources like CPU cycles, memory, and devices among multiple users and processes
  • Accounting
    • tracks resource usage for billing or performance monitoring
  • Protection and Security
    • protects system resources from unauthorized access and defends against external attacks

OS Services: User and Operating System Interface

  • Command-Line Interface (CLI)
    • the command interpreter as a special program that is running when a process is initiated or when a user first logs on in an interactive system
    • accepts text commands from the user (e.g. shells like bash in Linux)
    • the command interpreter can either contain the code for the commands or use the command name to load and execute a program
    • efficient for repetitive tasks and scripting
    • response is better than a GUI because it doesn't require a lot of bandwidth or resources
  • Graphical User Interface (GUI)
    • mouse-based window-and-menu system with a desktop metaphor
    • users interact for repetitive tasks and scripting
  • Touch-Screen Interface
    • used on mobile devices like smartphones and tablets
    • users interact with gestures like pressing and swiping

scripting: is like programming but not really, it doesn't turn it into machine code but instead is a series of commands and the OS handles that
command-interpreter: doesn't really have a menu

System Calls

_attachments/Pasted image 20250908132951.png

  • the primary interface to the services made available by the OS
    • calls are generally available as functions written in C/C++
    • certain low-level tasks are written using assembly-language instructions
    • C/C++ is used because there were 2 people in the Bell Labs named Dennis Ritchie and Ken Thompson. when they were younger, there was an old computer not being used and then they tried making their own system called Unix. they were using a combination of assembly and high-level language named D. they created C and recreated the whole OS using C. C creates native code (machine code for the target machine)
  • in an interactive system, it is possible to call/use 2+ system calls in a command
    • possible error conditions for each system call must be handled appropriately
  • run-time environment (RTE)
    • provides the system-call interface that links API function calls to the necessary kernel-level system calls
  • Passing Parameters
    • in registers (if few params)
    • in a block or table in memory, with the address passed in a register
    • placed onto the stack by the program

_attachments/Pasted image 20250908133636.png

  • created a copy of hello.c
  • cp is a command (technically a program) uses a lot of system calls (one is for reading hello.c and another one to create the second file, then another to copy the contents, then another just to load the program ~4 system calls)
  • the system call must also handle error conditions

Passing Parameters as a Table

_attachments/Pasted image 20250908134020.png

System Calls: Application Programming Interface

_attachments/Pasted image 20250908134104.png

  • notice the system call is write() but we also used printf() in the code, which "calls" write()

  • API's Role

    • the role of the API (Win32 API, POSIX API, etc.) allows the programmer to design their programs
    • most likely you won't use the system calls to create the application itself
    • they're also more straightforward and there's some sort of abstraction already
  • Portability

    • using a standard API allows a program to compile and run on any system that supports that same API, making the code portable across different operating systems
    • like you can use the same code in another OS given that
  • API vs System Call

    • an API function call is a high-level request
    • behind the scenes, the run-time environment (RTE) provides a system-call interface that handles the low-level details
    • this interface intercepts the API call and invokes the necessary system call in the operating system kernel
  • Example

    • a printf() function call in C is part of the standard C library (an API)
    • this library call is intercepted by the RTE, which then makes a low-level write() system call to the kernel to output the text to a device

_attachments/Pasted image 20250908134343.png

  • don't need to memorize this
  • there is an equivalent in Unix but the calls are different'

Other System Services

  • File Management: utilities to create/delete/copy/rename/manipulate files and directories
  • Status Information: programs that provide system information such as date, time, memory usage, and performance statistics
  • File Modification: text editors and other tools for creating and modifying files
  • Programming-Language Support: compilers, assemblers, debuggers, and interpreters
  • Program Loading and Execution: utilities to load programs into memory and start their execution
  • Communications: programs that provide connections for sending messages, remote login, and file transfer
  • Background Services: long-running processes (daemons) that handle specific system tasks (e.g. network listeners, print servers)
    • daemons are like background processes in Linux

Linkers and Loaders

_attachments/Pasted image 20250908135607.png

  • it's called a linker because it will use and create other object files to create the exe

  • a program resides on disk as a binary executable file (a.out or prog.exe)

  • to run on a CPU, the program is brought into memory and placed in the context of a process

  • compiler: translates source code into relocatable object files

    • recall in assembly: sometimes you compute for a memory address when you make code. that address is sometimes absolute (a specific addr), a program will not allow you to put it into a specific address because you might clash with another process (you give it an offset so that it becomes relocatable)
  • linker: combines relocatable object files and libraries into a single

  • loader: has to know where to put the program in the memory and to make sure it gets executed; loads the executable file into memory for execution

  • dynamic linking: libraries are not linked until execution time. (you don't want the executable to be big) this reduces the size of exe files and allows multiple processes to share a single copy of a library in memory (.dll are dynamically-linked libraries, equivalent in linux are .so)

    • it's not just one process "using" printf() or scanf(). there are processes sharing it so you don't have to give each process a copy of that library. but the OS also needs to know which process is using said library
    • malicious code is done through .dll or .so so that when it runs it affects the entire OS. it's privileged code once it becomes part of the kernel
  • relocation: the process of assigning final memory addresses to program parts during linking or loading

Why Applications are OS-specific

  • unique system calls: each OS provides a different set of system calls, which are the fundamental interface for applications
  • binary formats: applications are compiled into a specific binary format (e.g. ELF for Linux, PE for Windows) that the OS loader understands
  • CPU instruction sets: applications must be compiled for a specific CPU architecture (e.g. x86, ARM) even though it's the same operating system (ex. windows for Intel ≠ windows for ARM, would need a translator or virtual machine)
  • APIs and ABIs:
    • APIs provide a standardized set of functions for programmers
    • the Application Binary Interface (ABI) defines how binary code components interface for a given OS on a given architecture

OS Design and Implementation

  • design goals:
    • user goals: convenience, ease of use, reliability, safety, speed
    • system goals: ease of design, implementation, and maintenance; flexibility, reliability, efficiency
  • mechanisms and policies:
    • mechanisms determine how to do something (e.g. a timer for CPU protection)
    • policies determine what will be (e.g. how long the timer should be set)
    • separating policy from mechanism is cruicial for flexibility
  • implementation:
    • early OSes were written in assembly language
    • most modern OSes are written in higher-level languages (C/C++) for faster development, portability, and easier maintenance

Operating System Structure

  • Monolithic Structure: all kernel functionality is in a single, static binary file running in a single address space (e.g. early Unix, Linux)
    • all running in a single address space - efficient but hard to manage and extend
  • Layered Approach: the OS is broken into layers, where each layer uses the functions of only the layers below it (program using another program, process using another process)
    • easier to debug and maintain
    • can suffer from performance overhead (if the top is slow, everything else is slow)
  • Microkernels: moves nonessential components out of the kernel into user space.
    • communication occurs via message passing
    • provides greater security and extensibility but can have performance issues
  • Modules: the kernel has a set of core components and can dynamically link in additional services (modules) at runtime.
    • this is common design for modern OSes like Linux, MacOS, Windows
  • Hybrid Systems: combines different structure to optimize for performance, security, and usability (e.g. macOS combines a microkernel and monolithic structure while Android uses a Linux kernel with extensive middleware)

Building and Booting an OS

  • System Generation
    • process of configuring and compiling the OS for a specific hardware configuration
    • options range from full recompilation (from start to finish) to dynamically loading precompiled modules (compile just certain modules)
  • System Boot Process
    • a Bootstrap Program inside firmware (BIOS or UEFI) to run
    • locates and loads the OS kernel into memory
    • the kernel initializes hardware and mounts the root file system
    • the system starts daemons (background processes) and presents a login prompt or graphical interface
    • Linux: Root File System, Windows: C:/

Operating System Debugging

  • Failure Analysis:
    • Log Files: used to record system errors
    • Core Dumps: a capture of a process's memory at the time of failure
    • Crash Dumps: a capture of a kernel's memory at a time of a system crash (like BSOD on Windows)
  • Performance Monitoring
    • counters: OS keeps track of system activity through counters (e.g. number of system calls, I/O operations) (used by tools like ps and top/htop - htop is like task manager on Linux)
    • tracing: tools like strace and BCC collect data for specific events, such as system calls or I/O activity

_attachments/Pasted image 20250908141343.png

  • these are logs on the Linux operating system