https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2022F_Lecture_15 2026-04-05T22:41:57Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2022F_Lecture_15&diff=24135&oldid=prev 2022-11-09T02:21:20Z

<p>Created page with &quot;==Video== Video from the lecture given on November 8, 2022 is now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec15-20221108.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec15-20221108.cc.vtt auto-generated captions] Video is also available through Brightspace (Resources-&gt;Zoom meeting-&gt;Cloud Recordings tab) ==Notes== &lt;pre&gt; Lecture 15 ---------- * Washer delivery happening shortly...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on November 8, 2022 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec15-20221108.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/os-2022f/lectures/comp3000-2022f-lec15-20221108.cc.vtt auto-generated captions]<br /> Video is also available through Brightspace (Resources-&gt;Zoom meeting-&gt;Cloud Recordings tab)<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 15<br /> ----------<br /> <br /> * Washer delivery happening shortly, so I *may* have to step out for a few minutes, sorry<br /> * A2 is graded, I just need to post, should be later today<br /> * Midterm is being marked but we&#039;ll need until next week, sorry<br /> * update on Assignment 3<br /> - I have it mostly done but trying to figure out one thing, should be out in a day<br /> - but we&#039;re going to talk about it today anyway<br /> <br /> Assignment 3 from Fall 2021: 3000makefs.sh<br /> <br /> * When you run this script, you get what seems like a new system<br /> - it has its own filesystem with its own /etc, /usr, /bin, and so on<br /> <br /> This is part of the tech used to build small Linux systems<br /> <br /> Key technologies to understand:<br /> - making a filesystem in a file<br /> - chroot to make this new filesystem /<br /> - busybox<br /> <br /> What is busybox?<br /> - one program that has the (basic) functionality of an entire UNIX/Linux system (userland)<br /> - with a Linux kernel + busybox, you have a functional Linux system<br /> <br /> So why don&#039;t we use busybox all the time?<br /> - because its versions are rather basic<br /> <br /> How does a UNIX-like system start up?<br /> - three stages: bootloader, kernel startup, userland startup<br /> - the bootloader is responsible for loading the kernel<br /> - which may mean doing some hardware init<br /> - on modern Linux systems, most commonly this is GRUB<br /> - but can be a series of programs<br /> - the kernel then starts, this is what initializes the hardware,<br /> creates the process abstraction, manages all resources<br /> - we&#039;ll be exploring this more soon<br /> - userland starts with init<br /> - basically, all the things you can see with ps is userland<br /> (but not the ones in [])<br /> <br /> - the BIOS or EFI loads the bootloader<br /> - EFI can actually load a kernel directly<br /> <br /> &quot;init&quot; is the name given to the first process that runs on a UNIX system<br /> - always PID 1<br /> - it is its own parent process (the parent of 1 is 1)<br /> - when it terminates, the system shuts down<br /> <br /> Note that MOST processes sleep most of the time<br /> - background processes are waiting for something to do<br /> <br /> <br /> 3000makefs uses chroot to have a new root filesystem<br /> - so we can&#039;t see other filesystems unless we mount them from their devices<br /> - but we can still see the rest of the system<br /> - and in fact we aren&#039;t really isolated at all from things<br /> <br /> Have you heard of containers?<br /> - basically the same as a chroot environment, except we also split up processes, users, etc - everything in userspace<br /> - idea is to make systems separate, even though they share a kernel<br /> <br /> Whenever you see a loopback device as the device associated with a filesystem,<br /> it means the data for that filesystem is *in a file* on another filesystem<br /> <br /> /dev/loopX is just a device that is used to make a file behave like a block device<br /> <br /> So why is firefox and other software being distributed in containers?<br /> - because then Mozilla can package it up in a consistent way<br /> that will work the same on different systems<br /> - remember a container contains programs, libraries, and anything else you want<br /> - it is an &quot;entire system&quot;<br /> - to a first approximation then, anything else installed on the system can&#039;t<br /> mess with how firefox works, because they are kept separate<br /> <br /> <br /> Any modern program depends on many files<br /> - libraries, system data, config data, etc<br /> - if it acts strange/has a bug, the problem could be with the files<br /> it depends on, and not its code<br /> - containers package all this up so you get a consistent execution environment<br /> <br /> Why are we using loopback devices? To provide filesystem isolation<br /> - otherwise we can&#039;t make sure files in one container don&#039;t take away<br /> resources in another (say, a log file gets too big)<br /> <br /> So where is the code for the kernel?<br /> - basic kernel image: in /boot, vmlinuz...<br /> - kernel modules: /lib/modules/&lt;version&gt;<br /> - modules are bits of kernel code that are run at runtime as needed<br /> <br /> When we talk about userspace, we are talking about regular programs and their files<br /> When we talk about kernelspace, we are talking about the kernel &amp; modules<br /> - note the kernel doesn&#039;t load libraries or any other files generally<br /> - it facilitates programs accessing files<br /> <br /> We enter the kernel via two routes (which are two versions of the same interface):<br /> - system calls &amp; interrupts (from timers, keyboard, hard drive, network, etc)<br /> (also from dividing by zero, accessing<br /> invalid memory (segfault))<br /> <br /> We exit the kernel via the scheduler<br /> - determines what process to run next<br /> <br /> Basic flow of control for a system call<br /> <br /> Userspace Kernel space<br /> ------------------- ----------------<br /> make system call<br /> start system call dispatcher<br /> handle system call<br /> call scheduler<br /> - find progam that is in a runnable state<br /> - start it<br /> continue chosen program<br /> execution<br /> <br /> <br /> Implicit above is lots of saving and restoring of CPU state<br /> <br /> <br /> Note that when we return to userspace after a system call, we *generally* aren&#039;t going to run the process that made the system call next<br /> - we&#039;ll run another process that was waiting<br /> <br /> <br /> When you look in /proc and /sys, you are interacting directly with the kernel<br /> - interface to kernel data structures<br /> - but you access them using a filesystem interface<br /> &lt;/pre&gt;</div>

Soma