Operating Systems 2017F Lecture 15

Video

The video from the lecture given on Nov. 7, 2017 is now available. Unfortunately, the video cut out halfway through; audio is also available however.

Notes

In Class

Lecture 15
----------

What's a filesystem?
 - persistent data structure organized around fixed allocation units (blocks)
 - maps hierarchical names (keys) to values
 - provide a file-like API (open, read, write, close, etc)

What does it mean to "make" a filesystem?
 - initialize the data structure
 - "formatting" a disk

Physical versus logical size of a file
 - logical: the "size" your program sees when accessing the file
 - physical: how much space the file takes up on disk

Physical is in terms of blocks - fixed units of storage allocation
 - ext4 has 4k blocks
 - default for many command line utilities is 1k blocks


Kernel programming
 - you may destroy the system you are working on AT ANY TIME
 - HAVE GOOD BACKUPS
 - rsync is your friend



Kernel modules
 - way of splitting up kernel functionality so everything doesn't have to load
   at boot
    - code loaded as part of the initial boot image is hard to get rid of at
      runtime
 - why do we need modules? why not processes?
   - no new mechanisms
   - increased security (restricted access)
   - "microkernel" approach
   - instead of code talking in supervisor mode, processes do IPC
      - filesystems
      - drivers
      - networking
   - minix, QNX, GNU hurd
 - Linux is a "monolithic" kernel.  Why?
   - performance: context switches are expensive
     - techniques to make microkernels fast can be adopted by
       monolithic kernels to make them even faster
   - security benefit is illusory
     - if you control the filesystem process, you already own everything

Additional

--> Core kernel functionality is implemented via modules --> use ls mod to see modules that are loaded

What is a monolithic kernel? --> a type of OS architecture where the entire OS is working in kernel space --> can dynamically load/unload modules at runtime

make localmodconfig: --> takes output of ls mod and configures your kernel

ones.c program:

/dev/ones: --> permissions are read only

file_operations ones_fops(): --> defines what happens when you open a file, read from it, release tells you what happens when you're done with it (not the same thing as close)

ones_read(): --> len is the number of bytes to read --> offset tells you where you are in the file --> put_user() takes care of whatever needs to be done to write into that process properly

ones_release:

Why are we using printk instead of printf? --> printf is not yet defined (ie. C library is not available in the kernel) --> kernel doesn't depend on any libraries, all code belongs to the kernel itself --> printk is the kernel's own implementation of printf (outputs to the kernel log --> /var/log/kern.log)

vfs = virtual filesystem layer

How do we limit access to user space processes? --> Do a permission check

--> kernels need to be updated regularly to correct bugs that make the kernel vulnerable to programs trying to gain access to important user space processes --> unlikely() = tells you that this branch is not likely to be taken, optimize the current path

vfs_read:

file->f_op->read: --> this is how our read function will be called