Operating Systems 2022F Lecture 18
Video
Video from the lecture given on November 17, 2022 is now available:
Video is also available through Brightspace (Resources->Zoom meeting->Cloud Recordings tab)
Notes
Lecture 18 ---------- Side note: - there are only *three* rendering engines that can handle the modern web: - Blink (Chrome), a fork of WebKit - WebKit (Safari) - Gecko (Firefox) Note Edge uses Blink On iOS everything must use WebKit, so even Firefox on iOS uses WebKit not Gecko (On Android things are different, Firefox is its own thing there) A3 is due on Monday, Nov. 21st - will be accepted until just before class on Tuesday, Nov. 22nd - I'll be posting solutions and going over them in class on the 22nd - so T5 & T6 is also due then A4 will be released before Nov. 21st - T7, T8, & T9 will be due when A4 is due on Dec. 7th Tutorial 8 (cont.) ---------- Remember that all devices have a major and minor number - major number designates the driver - minor specifies which device (in case one driver can be responsible for multiple devices) When we create a new device with a module, we must allocate a new major number for this device (dynamically) and then we can number off our own devices for the minor number (so, probably just use 0 if we just have one instance) In ones_read(), why do we call put_user() rather than just writing something like *buf++ = '1'; Remember that buf is a pointer to userspace, i.e., the address space of a specific process! - we have to treat accessing userspace differently from regular kernel data Remember that every process, and the kernel itself, have their own address space Also, note that ones_read() only writes a finite amount. Why does reading from /dev/ones appear infinite? - where is the loop that makes it infinite? Is it in the kernel? - NO, it is in userspace! - it becomes infinite because programs keep making read system calls because they don't get an end of file "current" in the Linux kernel always refers to the currently running task (process/thread) - in other words, the task that made the system call that got us into the kernel - in the kernel, a "task" is the abstraction applied to kernel threads and processes - a task is something that can be run on a core How did I know to use task_tgid_vnr() to get the process ID of the current task? - look at the source for the getpid system call! When you want to do something in the kernel, best bet is to find source from a part of the kernel that does something similar - then you can adapt what it does to your problem!