https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Operating_Systems_2020W_Lecture_17 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_17&diff=22582&oldid=prev 2020-03-20T02:43:04Z

<p>Created page with &quot;==Video== The video from the lecture given on March 13, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec17-20200313.m4v is now available]....&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> The video from the lecture given on March 13, 2020 [https://homeostasis.scs.carleton.ca/~soma/os-2020w/lectures/comp3000-2020w-lec17-20200313.m4v is now available].<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 17<br /> ----------<br /> <br /> - doing things remotely<br /> - discuss /dev/ones<br /> - discuss newgetpid<br /> - clock algorithm?<br /> <br /> <br /> Understanding user data in the kernel<br /> - the kernel, like any C program, deals with pointers all the time<br /> - most of the time, kernel pointers refer to kernel data structures<br /> - i.e., data that belongs to the kernel, residing in the kernel&#039;s<br /> virtual address space<br /> - but, the kernel also has to be able to get data from userspace programs,<br /> particularly as parameters for system calls. These pass in pointers,<br /> but these arguments are pointers to *userspace* data structures and<br /> functions - i.e., ones that are in the calling process&#039;s address space<br /> - so the kernel has to keep track of userspace pointers and handle<br /> them specially (for safety and security reasons)<br /> - annotated with __user<br /> - accessed using special functions such as get_user, put_user<br /> - NEVER use userspace pointers like regular (kernel) pointers!<br /> <br /> Pointers to functions and data in the kernel work just like userspace<br /> - this includes ones in kernel modules<br /> - but, they are running in supervisor mode on the CPU so can access<br /> all hardware, all resources<br /> <br /> &quot;current&quot; is a special global variable available whenever the kernel<br /> is processing a system call<br /> - refers to the task_struct associated with the process making<br /> the system call<br /> - many processes can be making system calls at the same time, so<br /> there are many &quot;current&quot; pointers at any time<br /> - we don&#039;t have to think about current in a kernel module,<br /> the rest of the kernel takes care of it, it will magically be right<br /> <br /> Note that if you are writing a real device driver (dealing with<br /> hardware), your module&#039;s code will be called in response to events<br /> (interrupts) generated by the hardware<br /> - functions called when servicing interrupts have no &quot;current&quot; as<br /> they aren&#039;t being called in the context of a system call<br /> <br /> Why not build in code in the kernel? Why put it in a module?<br /> - we want everything in a module that we can because modules<br /> can be removed<br /> - code that is just part of the initially loaded kernel is always present,<br /> so you should want it all the time<br /> - devices vary between systems, so it is natural for device drivers<br /> to be in kernel modules - but almost any kernel functionality can<br /> be in a module (and most is)<br /> <br /> Traditional UNIX kernels had no notion of modules<br /> - instead, you specify configuration options at compile time and<br /> build a single kernel image<br /> - different systems would have different specialized kernels<br /> - could work because those kernels ran on relatively few kinds of hardware<br /> (all proprietary, specific to one company generally)<br /> <br /> If you want to look at interrupts and how they work, look in the textbook<br /> - http://pages.cs.wisc.edu/~remzi/OSTEP/file-devices.pdf<br /> - look at for context!<br /> <br /> Kernel modules are kernel version specific<br /> - some source-level portability, but very little binary portability<br /> - new kernel -&gt; compile modules from source<br /> <br /> What functionality cannot be put into a module?<br /> - well, anything needed to actualy load modules...<br /> - so basic processes, memory management, etc need to all be built in<br /> <br /> <br /> What if modules have the code needed to get the root filesystem online?<br /> - filesystem drivers, hard drive drivers, others?<br /> - solution: initial ram disks (initrd)<br /> <br /> initrd allows you to limit what is in the base kernel<br /> <br /> Idea: boot loader loads a RAM disk with kernel modules along with<br /> main kernel image<br /> <br /> Note that kernel modules are mostly loaded and unloaded via userspace<br /> - but the kernel can generate events that cause userspace programs<br /> to load modules<br /> - example: insert a USB device, kernel will send an event to a userspace<br /> daemon to make sure the modules are loaded to handle the device<br /> (actually, that used to be the case, not sure if udev does that now...)<br /> <br /> Can kernel modules spawn processes? Not quite, as a new process requires a system call.<br /> - there are kernel threads, you can see them in a process listing<br /> (the ones in [])<br /> <br /> The standard boot loader for Linux systems is GRUB<br /> - is the first thing that loads on boot<br /> - GRUB loads the chosen kernel and associated initrd<br /> - provides a menu interface so you can choose which kernel to boot<br /> (or on multi-os setups, another OS to boot)<br /> <br /> (Before GRUB there was LILO. GRUB is better!)<br /> <br /> If you break GRUB your system won&#039;t boot. Remember that!<br /> <br /> Every OS has its own boot loader<br /> - Windows has its own<br /> - MacOS has its own<br /> - the *BSDs have their own<br /> <br /> Sometimes you have to use a boot loader to load a boot loader<br /> - use GRUB to load the windows boot loader which loads windows<br /> - can get...convoluted<br /> <br /> Linux tries to be flexible, but not all boot loaders can load it directly<br /> <br /> initrd is a small Linux system (minus the kernel), purpose is just to load<br /> kernel modules<br /> &lt;/pre&gt;</div>

Soma