https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2019F_Lecture_17 2026-05-18T20:02:23Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2019F_Lecture_17&diff=22539&oldid=prev 2020-03-20T02:08:40Z

<p>Created page with &quot;==Video== Video from the lecture given on November 8, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec17-20191108.m4v is now available]....&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on November 8, 2019 [https://homeostasis.scs.carleton.ca/~soma/os-2019f/lectures/comp3000-2019f-lec17-20191108.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 17<br /> ----------<br /> <br /> special files: files that aren&#039;t directories or regular files<br /> <br /> Three kinds of special files:<br /> * character devices<br /> * block devices<br /> * named pipes/FIFOs<br /> <br /> first letter of permission block:<br /> - regular file (hard links)<br /> d directory<br /> l symbolic link<br /> <br /> b block device<br /> c character device &lt;--- these three are &quot;special files&quot;<br /> p named pipe/FIFO<br /> <br /> A special file really isn&#039;t a file; instead, it is an interface that<br /> uses a file-like API<br /> - you use standard file system calls to do weird things<br /> <br /> Note that special files way predate things like /proc<br /> <br /> Why do we have them?<br /> * block devices represent mass storage (disks)<br /> * character devices represent most other I/O devices<br /> * pipes are inter-process communication (IPC)<br /> <br /> <br /> Why do we need block devices?<br /> - manipulate mass storage, e.g.<br /> - format disks (lay down filesystem on storage)<br /> - repair/recover filesystems on disk<br /> - low-level backup<br /> <br /> Normally you shouldn&#039;t be playing with block devices!<br /> - because you interact with them indirectly via mounted filesystems<br /> <br /> The kernel implementation of block devices is a bit complex<br /> - lots of machinery for caching<br /> <br /> If you wanted to learn about how block devices work, look at the implementation of loopback devices, /dev/loopX<br /> <br /> Why &quot;loopback&quot;<br /> - normally you have this situation<br /> <br /> filesystem &lt;-- /home/soma/foo<br /> mass storage &lt;-- /dev/sda<br /> <br /> So here foo is stored on /dev/sda<br /> <br /> -- but with a loopback filesystem<br /> <br /> filesystem &lt;-- /mnt/somefile<br /> loopback &lt;-- /dev/loop0<br /> filesystem &lt;-- /home/soma/bigfile<br /> mass storage &lt;-- /dev/sda<br /> <br /> /home/soma/bigfile is mounted on /mnt<br /> storage for bigfile (and hence somefile) is actually on /dev/sda<br /> <br /> <br /> Loopback devices are very useful for<br /> - learning about filesystems<br /> - making ISOs (CD/DVDs)<br /> - accessing virtual disks of virtual machines<br /> <br /> 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<br /> <br /> <br /> Character devices<br /> - everything but mass storage<br /> - tapes, mouse, keyboard, ttys<br /> <br /> <br /> named pipes/FIFOs<br /> - examples of the producer/consumer problem<br /> - need to pause producer when consumer gets behind<br /> - need to pause consumer when producer gets behind<br /> - use buffering to allow each to run at their own pace (when not paused)<br /> <br /> General pattern<br /> - producer runs until it fills a buffer. When buffer is full, pause producer<br /> - consumer runs until buffer is empty. When buffer is empty, pause consumer<br /> - must resume producer when buffer is no longer full<br /> - must resume consumer when buffer is no longer empty<br /> <br /> <br /> What is the mechanism for pausing and resuming with pipes on UNIX?<br /> - put the process to sleep when it reads or writes<br /> - producers write, consumers read<br /> <br /> How do we make pipes?<br /> - at command line, use |<br /> - in a program, use pipe() or pipe2() and generally dup2()<br /> - consumer gets first fd, puts it on stdin (fd 0)<br /> - producer gets second fd, puts it on stdout (fd 1) &lt;--- said stdin in lecture, that is wrong<br /> - note the producer is the one to the left of |, consumer is to the right<br /> - mkfifo or mknod p<br /> - allows for &quot;persistent&quot; pipes that are used by multiple processes<br /> at different times, a way to do rendezvous<br /> <br /> eBPF versus modules<br /> - both let you inject code into a Linux kernel<br /> - eBPF is safe and restricted<br /> - modules are not safe and are not restricted<br /> &lt;/pre&gt;</div>

Soma