Operating System Structure

Objectives

1. Identify and understand several different OS Structures.

Notes

• This is 2.8, you really should read this one.
• This is current/historic prospective.
  • And it is engineering.
  • It represents best practices today
  • But who knows what clever person will discover/think of something new.
• They point out that this is related to how you structure the program for the kernel.
• But you might need a bit of background first.
  • There are numerous ways that programs can communicate.
  • They can both write to the same file, very primitive.
  • They can have shared memory, better
  • The can use a kernel supplied communications channel,
    • pipe or unix domain socket.
  • Look at dieServer.cpp and dieClient.cpp for a simple example.
• Monolithic Structure
  • The traditional way to build a kernel.
  • Most kernels were this at some point.
  • All code is contained in a single, huge program.
  • Take a look at Figure 2.12 page 82
  • Such kernels
    • Were the standard for a long time.
    • Are huge programs.
    • Are extremely efficient, as they have no infrastructure to delay a call.
      • Think about [] for indexing an array vs .at(), vs direct array access

        // direct
        // multiply, memory fetch
        base[index*sizeof(element)]
        
        // function call, return
        // multiply, memory fetch
        element operator [](int index) {
            offset index * sizeof(element);
            return base[offset]
        }
        
        // function call, return
        // comparison, branch, load, comparison, branch
        // multiply, memory fetch
        element at(int index) {
           if (index > 0 and index < size) {
                offset = base + index * sizeof(element);
                return base[offset]
           } else {
                throw exception
           }
        } 

• Layered approach
  • They describe a system where the kernel is built in layers.
  • They discuss in theory how a layered system is implemented.
  • They discuss how such systems are easier to maintain and implement.
  • Then they say that few OS's use this approach
    • Because there does not appear to be a natural decomposition of an OS to this system.
  • TCP/IP is an example
    • The network is DESIGNED with different layers of responsibility.
    • To send a message it is sent down through the different layers.
    • Each does it's job and sends it down to the next layer.
    • And reverse on the receiving side.
  • The major problem with TCP/IP is delay caused by the layers.
• Microkernels
  • Several kernels have been built with this idea.
  • The microkernel provides the absolutely required services needed.
    • Memory management
    • Interprocess communications (minimal)
    • Scheduling
  • Everything else is run in user space as a client.
  • This leads to smaller programs for each part
    • Decreasing development time
    • And errors
  • But it increases time to perform services.
    • The book says to access a file
    • The client program contacts the kernel.
    • Which then interacts with the file server program.
    • And back.
  • See picture page 85.
• The latest method seems to be a module approach.
  • The kernel can load modules to perform services.
  • Either at boot or dynamically
  • It is not really layered as the libraries/modules become part of the kernel
  • It is not a microkenel for the same reason.
  • These appear to be mostly for
    • Device, network, and file system drivers
    • Other odd-ball extensions.
  • lsmod on mirkwood reveals
    • quite a few gpu related modules.
    • Multiple inet related modules
    • zram
      • reference
      • And here
      • This appears to create a compress memory based block device.
        • Used to store memory pages
        • The idea is to set up a device that compresses data on write and uncompresses data on read.
        • This is an extension of the kernel