Operating Systems 2017F Lecture 12

From Soma-notes
Revision as of 20:20, 17 October 2017 by Soma (talk | contribs) (Created page with "==Video== Video from the lecture given on October 17, 2017 [http://homeostasis.scs.carleton.ca/~soma/os-2017f/lectures/comp3000-2017f-lec12-17Oct2017.mp4 is now available]....")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Video

Video from the lecture given on October 17, 2017 is now available.

Notes

In-Class

Lecture 12
----------

* segmentation
* inode fields
* page table entries
* scheduling


paging, blocks - fixed-sized memory allocations
  - typically 4K or 8K (can have some huge ones)

paging only works well if you have MMU
  - need page tables, TLB
  - do "table lookup" on every memory access

How do you manage memory without paging?

* put everything at a fixed place in memory
  - useful if you have very little RAM

* put code, data into "segments"
  - semantic units of memory (stack, heap, "text")
  - still use this terminology when referring to parts of a binary program

Segments:
* a variable-sized block of memory
* base: starting address
* bound: how long is it

Key idea is segments can be placed in different parts of the address space
 - to move, you just change the base
 - code inside a segment refers to rest of segment via offsets
 - on each memory access, CPU adds segment register to offset to get
   physical address
 - having a base address with offsets is still used in userspace

16-bit x86 (8086) is a segmented architecture
 - memory accesses are mostly relative to a segment base address

standard modes for 32-bit x86 (80386+) and 64-bit x86 (amd64) is "flat"
 - segmented memory can be a pain because it can "wrap around" - going past
   the last address can put you in the first, or it just gives you an error


inode fields
------------
 - stat, lstat gives you details on an inode
 - inodes allow access to contents of files and have the key metadata
   - size
   - "mode" - rwx, others
   - owner, group

Users, groups
-------------
users and groups are used to restrict access
 - each file has a user and group associated with it, permissions
 - each process has a user and group

What if file ownership/permissions are "wrong"?

In UNIX, the "root" user has all power
 - can bypass all permission checks
 - (unless you are on a mandatory access control system such as seLinux)
 - VERY DANGEROUS
 
(Equivalent to an administrator account on Windows)

Page table entries
------------------

page tables are "tables" (really very wide trees) of page table entries

page table entries contain the top bits of the physical address along with
metadata:
 - readable?
 - writable?
 - executable?

most pages are either r+x (code) or r+w (data)

- valid?
- dirty?
  - is data in page different from data on disk?

other bits to help with deciding what pages to keep in RAM or not
 - e.g., when was it last accessed