Operating Systems 2019F Lecture 17

From Soma-notes
Jump to navigation Jump to search

Video

Video from the lecture given on November 8, 2019 is now available.

Notes

Lecture 17
----------

special files: files that aren't directories or regular files

Three kinds of special files:
* character devices
* block devices
* named pipes/FIFOs

first letter of permission block:
 -   regular file  (hard links)
 d   directory
 l   symbolic link

 b   block device
 c   character device      <--- these three are "special files"
 p   named pipe/FIFO

A special file really isn't a file; instead, it is an interface that
uses a file-like API
  - you use standard file system calls to do weird things

Note that special files way predate things like /proc

Why do we have them?
 * block devices represent mass storage (disks)
 * character devices represent most other I/O devices
 * pipes are inter-process communication (IPC)


Why do we need block devices?
 - manipulate mass storage, e.g.
   - format disks (lay down filesystem on storage)
   - repair/recover filesystems on disk
   - low-level backup

Normally you shouldn't be playing with block devices!
 - because you interact with them indirectly via mounted filesystems

The kernel implementation of block devices is a bit complex
 - lots of machinery for caching

If you wanted to learn about how block devices work, look at the implementation of loopback devices, /dev/loopX

Why "loopback"
 - normally you have this situation

  filesystem    <-- /home/soma/foo
  mass storage  <-- /dev/sda

So here foo is stored on /dev/sda

-- but with a loopback filesystem

  filesystem   <-- /mnt/somefile
  loopback     <-- /dev/loop0
  filesystem   <-- /home/soma/bigfile
  mass storage <-- /dev/sda

/home/soma/bigfile is mounted on /mnt
storage for bigfile (and hence somefile) is actually on /dev/sda


Loopback devices are very useful for
 - learning about filesystems
 - making ISOs (CD/DVDs)
 - accessing virtual disks of virtual machines

Note the loopback device just allows us to reuse the filesystem implementations already in the kernel.  You could always pull them out and treat the file as one with a really baroque storage format


Character devices
 - everything but mass storage
 - tapes, mouse, keyboard, ttys


named pipes/FIFOs
 - examples of the producer/consumer problem
 - need to pause producer when consumer gets behind
 - need to pause consumer when producer gets behind
 - use buffering to allow each to run at their own pace (when not paused)

General pattern
 - producer runs until it fills a buffer.  When buffer is full, pause producer
 - consumer runs until buffer is empty.  When buffer is empty, pause consumer
 - must resume producer when buffer is no longer full
 - must resume consumer when buffer is no longer empty


What is the mechanism for pausing and resuming with pipes on UNIX?
 - put the process to sleep when it reads or writes
 - producers write, consumers read

How do we make pipes?
 - at command line, use |
 - in a program, use pipe() or pipe2() and generally dup2()
   - consumer gets first fd, puts it on stdin (fd 0)
   - producer gets second fd, puts it on stdout (fd 1)  <--- said stdin in lecture, that is wrong
   - note the producer is the one to the left of |, consumer is to the right
 - mkfifo or mknod p
   - allows for "persistent" pipes that are used by multiple processes
     at different times, a way to do rendezvous

eBPF versus modules
 - both let you inject code into a Linux kernel
 - eBPF is safe and restricted
 - modules are not safe and are not restricted