https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Lecture_20 2026-06-02T22:26:50Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2020W_Lecture_20&diff=22621&oldid=prev 2020-03-25T20:09:00Z

<p>Created page with &quot;==Video== Video from the lecture given on March 25, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec20-20200325.m4v is now available]. ==...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture given on March 25, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec20-20200325.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 20<br /> ----------<br /> - Assignment 3 solutions<br /> - scheduling<br /> <br /> If you are a few minutes late in submitting your assignment it is okay, but please upload your solutions now<br /> <br /> Assignment 4 is due April 3rd<br /> - but you&#039;re answering multiple choice questions, posted by Monday<br /> - General questions are up now, you should try answering those<br /> (solutions for them will be posted but we won&#039;t grade answers,<br /> will just do auto-grading of multiple choice questions)<br /> <br /> Final exam will be similar to the midterm, but covering the whole class<br /> - difficulty will be similar as if you look back at the midterm,<br /> open book would only have helped for a few questions<br /> <br /> You&#039;ll submit a text file via cuLearn<br /> - I&#039;ll give you all a template for the text file along with the questions<br /> - Please fill out the template so we can use scripts to assist with grading<br /> <br /> Final exam grade replaces midterm if you do better on the final<br /> <br /> (And I will make adjustments to compensate for A3 difficulty, so<br /> focus on learning the material!)<br /> <br /> Review session for final<br /> - last class will be solutions for A4 plus exam review<br /> <br /> Participation marks cannot lower your grade<br /> - will also calculate grades with 20% assignments, 20% tutorials, 0%<br /> participation<br /> <br /> So hopefully most of you will get a 4% boost from participation<br /> <br /> Interviews will start by April 20th.<br /> <br /> <br /> Assignment 3 solutions<br /> - Q1: pipes (named &amp; created by pipe())<br /> - Q2: understanding the logic behind semaphores and condition variables<br /> (separate from their implementation)<br /> Why two cores?<br /> - without 2 cores, only one process/thread can execute at a time<br /> - means that the only concurrency you have is one being interrupted<br /> at arbitrary times. (In practice it tends not to be so arbitrary)<br /> - e.g., you&#039;ll see deadlock much less often with only one core<br /> - Q3: see how to make threads, compare with making processes with fork<br /> - multiple ways to get a working implementation<br /> - TAs will do their best to grade fairly, don&#039;t need to do exactly<br /> what was in the solutions<br /> - probably better to just add parameters to the shared struct!<br /> - main thing is you used threads and not processes,<br /> and got rid of the mmap and the shared memory hints to pthread<br /> (calls to setpshared)<br /> - Q4: understand the steps in creating a device in the kernel<br /> see that the device files created are nothing special,<br /> could have been created manually<br /> (note that device files in /dev/pts are an exception, because<br /> they are actually device files in a special filesystem,<br /> so have weird semantics. Devices in /dev are &quot;normal&quot;)<br /> you can copy device files between filesystems most of the time,<br /> for &quot;normal&quot; device files<br /> <br /> - Q5: understand how character device modules work<br /> - how read/write access is determined<br /> - how the fops struct controls what functions are<br /> called for file operations<br /> understand the significance of uid vs euid (vs. pid)<br /> - be able to express in english<br /> get experience navigating the kernel source code<br /> - see how to call kernel code by following examples in<br /> the code base<br /> understand better the task abstraction for processes &amp; threads<br /> kernel space vs user space (and transferring data safely between them)<br /> <br /> using helper function in the kernel is the best way to access things<br /> - I got a bit sloppy in part when I directly accessed task-&gt;cred-&gt;uid<br /> <br /> How do debug kernel modules?<br /> - printk is most straightforward<br /> - there are ways to use gdb (kgdb) but the setup is non-trivial<br /> - there&#039;s a reason why it is good to code in userspace!<br /> - and why eBPF is so wonderful!<br /> Why used current_ns? because seems dangerous to use any other namespace (to me)<br /> - but I could be convinced<br /> Q6: realize that some things (like usernames) are purely in userspace,<br /> kernel knows nothing about them<br /> <br /> <br /> (Optional info)<br /> Traditionally on Linux systems, logs are in /var/log<br /> - /var is for data that is variable (get it?)<br /> - logs can be put there by individual applications, normally in<br /> their own subdirectory<br /> - traditionally syslogd would handle the other log files, but<br /> now that is part of systemd<br /> - in fact, with systemd these text logs are copies of data in a binary<br /> log (stored in /var/log/journal), can read this log directly<br /> with journalctl<br /> - kernel logs go to the console initially, then go to a userspace program<br /> that has requested access to the kernel logging buffer<br /> - traditionally klogd, now part of systemd<br /> - copies of kernel logs are put in /var/log/kern.log, can<br /> get current ones with dmesg<br /> - log rotation is responsible for files with a number after them<br /> - periodically current logs are moved to a numbered log file<br /> - older logs are compressed, and oldest are deleted<br /> - keeps logs from taking up all of the disk (generally)<br /> - journalctl has lots of ways to select which logs are shown<br /> - or you use grep on the text logs<br /> <br /> systemd is a project to replace much of the core userspace functionality on<br /> linux systems. Controversial but now ubiquitous. Replaces lots of low level<br /> stuff including<br /> - init<br /> - networking<br /> - logging<br /> - kernel module loading<br /> - container management (partial)<br /> - getty (login from a console)<br /> - time management<br /> - others<br /> Complaint is systemd replaced stuff that wasn&#039;t broken. Response is a<br /> unified approach to this functionality provides lots of benefits<br /> (power management, fast boot in particular)<br /> <br /> See https://www.freedesktop.org/wiki/Software/systemd/<br /> <br /> <br /> Process states<br /> - # cores = # processes (maximum) in the running state<br /> - everyone else is waiting for some reason<br /> - waiting for I/O (e.g. waiting for the disk)<br /> - sleeping (nothing to do)<br /> - idle (waiting to be scheduled, to get access to a core)<br /> <br /> grep State /proc/*/status | grep -v idle | grep -v sleeping | less<br /> - to see what is not sleeping or idle<br /> &lt;/pre&gt;</div>

Soma