Operating Systems 2017F Lecture 15: Difference between revisions
| Line 67: | Line 67: | ||
--> can dynamically load/unload modules at runtime | --> can dynamically load/unload modules at runtime | ||
make localmodconfig: | '''make localmodconfig:''' | ||
--> takes output of ls mod and configures your kernel | --> takes output of ls mod and configures your kernel | ||
ones.c program: | '''ones.c program:''' | ||
/dev/ones: | '''/dev/ones:''' | ||
--> permissions are read only | --> permissions are read only | ||
file_operations ones_fops(): | '''file_operations ones_fops():''' | ||
--> defines what happens when you open a file, read from it, release tells you what happens when you're done with it (not the same thing as close) | --> defines what happens when you open a file, read from it, release tells you what happens when you're done with it (not the same thing as close) | ||
ones_read(): | '''ones_read():''' | ||
--> len is the number of bytes to read | --> len is the number of bytes to read | ||
--> offset tells you where you are in the file | --> offset tells you where you are in the file | ||
--> put_user() takes care of whatever needs to be done to write into that process properly | --> put_user() takes care of whatever needs to be done to write into that process properly | ||
ones_release: | '''ones_release:''' | ||
Why are we using printk instead of printf? | '''Why are we using printk instead of printf?''' | ||
--> printf is not yet defined (ie. C library is not available in the kernel) | --> printf is not yet defined (ie. C library is not available in the kernel) | ||
--> kernel doesn't depend on any libraries, all code belongs to the kernel itself | --> kernel doesn't depend on any libraries, all code belongs to the kernel itself | ||
| Line 92: | Line 92: | ||
vfs = virtual filesystem layer | vfs = virtual filesystem layer | ||
How do we limit access to user space processes? | '''How do we limit access to user space processes?''' | ||
--> Do a permission check | --> Do a permission check | ||
| Line 98: | Line 98: | ||
--> unlikely() = tells you that this branch is not likely to be taken, optimize the current path | --> unlikely() = tells you that this branch is not likely to be taken, optimize the current path | ||
vfs_read: | '''vfs_read:''' | ||
file->f_op->read: | '''file->f_op->read:''' | ||
--> this is how our read function will be called | --> this is how our read function will be called | ||
Revision as of 15:13, 8 November 2017
Video
The video from the lecture given on Nov. 7, 2017 is now available. Unfortunately, the video cut out halfway through; audio is also available however.
Notes
In Class
Lecture 15
----------
What's a filesystem?
- persistent data structure organized around fixed allocation units (blocks)
- maps hierarchical names (keys) to values
- provide a file-like API (open, read, write, close, etc)
What does it mean to "make" a filesystem?
- initialize the data structure
- "formatting" a disk
Physical versus logical size of a file
- logical: the "size" your program sees when accessing the file
- physical: how much space the file takes up on disk
Physical is in terms of blocks - fixed units of storage allocation
- ext4 has 4k blocks
- default for many command line utilities is 1k blocks
Kernel programming
- you may destroy the system you are working on AT ANY TIME
- HAVE GOOD BACKUPS
- rsync is your friend
Kernel modules
- way of splitting up kernel functionality so everything doesn't have to load
at boot
- code loaded as part of the initial boot image is hard to get rid of at
runtime
- why do we need modules? why not processes?
- no new mechanisms
- increased security (restricted access)
- "microkernel" approach
- instead of code talking in supervisor mode, processes do IPC
- filesystems
- drivers
- networking
- minix, QNX, GNU hurd
- Linux is a "monolithic" kernel. Why?
- performance: context switches are expensive
- techniques to make microkernels fast can be adopted by
monolithic kernels to make them even faster
- security benefit is illusory
- if you control the filesystem process, you already own everything
Additional
--> Core kernel functionality is implemented via modules --> use ls mod to see modules that are loaded
What is a monolithic kernel? --> a type of OS architecture where the entire OS is working in kernel space --> can dynamically load/unload modules at runtime
make localmodconfig: --> takes output of ls mod and configures your kernel
ones.c program:
/dev/ones: --> permissions are read only
file_operations ones_fops(): --> defines what happens when you open a file, read from it, release tells you what happens when you're done with it (not the same thing as close)
ones_read(): --> len is the number of bytes to read --> offset tells you where you are in the file --> put_user() takes care of whatever needs to be done to write into that process properly
ones_release:
Why are we using printk instead of printf? --> printf is not yet defined (ie. C library is not available in the kernel) --> kernel doesn't depend on any libraries, all code belongs to the kernel itself --> printk is the kernel's own implementation of printf (outputs to the kernel log --> /var/log/kern.log)
vfs = virtual filesystem layer
How do we limit access to user space processes? --> Do a permission check
--> kernels need to be updated regularly to correct bugs that make the kernel vulnerable to programs trying to gain access to important user space processes --> unlikely() = tells you that this branch is not likely to be taken, optimize the current path
vfs_read:
file->f_op->read: --> this is how our read function will be called