Talk:COMP 3000 Final Exam Study Guide 2012: Difference between revisions
answered first few questions |
flocking |
||
(2 intermediate revisions by the same user not shown) | |||
Line 24: | Line 24: | ||
* signal handling: what can be handled, who calls them, how do they work? | * signal handling: what can be handled, who calls them, how do they work? | ||
* Major system calls: fork, execve, open, close, read, write, lseek, mmap | * Major system calls: fork, execve, open, close, read, write, lseek, mmap | ||
fork: creates a new process and copies the current process image into the newborn execution context | |||
execve: fills the current process with a new an image from a path. | |||
int execve(const char *filename, char *const argv[],char *const envp[]); | |||
open: grants access to file. Returns a file descriptor referring to that file or -1 for errors. Updates OS table of open files. | |||
int open(const char *pathname, int flags, mode_t mode); | |||
close: terminates access to a file. Flushes buffer, free's allocated space, updates metadata and a buncha other cool stuff. | |||
int close(int fd); | |||
read: reads a certain amount of bytes (count) from a file descriptor (fd) to a buffer pointer (*buf) | |||
ssize_t read(int fd, void *buf, size_t count); | |||
write: writes count bytes to a file descriptor fd from buffer pointed at by *buf. Returns number of bytes written, 0 or -1 for errors. Writes after current file offset (see lseek) | |||
ssize_t write(int fd, const void *buf, size_t count); | |||
lseek: reposition read/write file offset | |||
off_t lseek(int fd, off_t offset, int whence); | |||
whence = SEEK_SET SEEK_CUR SEEK_END | |||
mmap: requests a new memory mapping of a given space within the current process's virtual memory address space. Similar to malloc. | |||
see [http://stackoverflow.com/questions/3642021/what-does-mmap-do an answer on SO] | |||
* The process hierarchy and zombie processes | * The process hierarchy and zombie processes | ||
Basically a tree rooted at init. Every node's parent is its parent process. | |||
Zombie processes are children that have stopped running but haven't been reaped by parents. They still exist on the OS's process table. You get rid of them by killing the parent. | |||
Unix uses terrible metaphors. | |||
* Files, directories, inodes, sparse files | * Files, directories, inodes, sparse files | ||
* file permissions: users, groups, others, rwx, where are they stored? | * file permissions: users, groups, others, rwx, where are they stored? | ||
* Basic file-level concurrency, flock | * Basic file-level concurrency, flock | ||
Flock uses a file based mutex. -x means exclusive lock, 200> writes that file on file descriptor 200. The file is located where most locks are... /var/lock/mylockfile.lock | |||
( flock -x 200 | |||
... | |||
) 200> /var/lock/mylockfile.lock | |||
* Ubuntu/Debian alternatives system | * Ubuntu/Debian alternatives system | ||
Series of symlinks pointed to and from various binaries. Allows you to run multiple versions of binaries (netcat tradition/netcat bsd) and set defaults (www-browser --> links2). The heart of the system lies in /etc/alternatives. | |||
* Basic package management on Ubuntu: apt-get, dpkg | * Basic package management on Ubuntu: apt-get, dpkg | ||
dpkg: installs, keeps track and maintains debian packages. | |||
apt-get: wrapper for dpkg that finds and downloads packages and satisfies dependencies. | |||
* Basic package development: dpkg-dev, dpkg-buildpackage, fakeroot | * Basic package development: dpkg-dev, dpkg-buildpackage, fakeroot | ||
* filesystem administration: mkfs, fsck, mount, /etc/fstab | * filesystem administration: mkfs, fsck, mount, /etc/fstab | ||
* block versus character devices and how they are used | * block versus character devices and how they are used | ||
* upstart and init | * upstart and init | ||
upstart is init. It controls the boot process and when whatever process gets run. We call these runlevels. | |||
* init and process hierarchy | * init and process hierarchy | ||
Init has PID 1 | |||
* upstart versus System V init scripts | * upstart versus System V init scripts | ||
System V is a few shell scripts being run sequentially, perfect for single core processors from the 90's. | |||
Upstart takes concurrency to heart. Uses dependencies. | |||
* upstart scripts, basic structure, purpose, common options | * upstart scripts, basic structure, purpose, common options | ||
* SysV init scripts, basic structure and purpose | * SysV init scripts, basic structure and purpose | ||
* device drivers | * device drivers | ||
Code used by the kernel to communicate with hardware. It's an abstraction for the hardware. The kernel creates another abstraction which will be used by users and developers. | |||
* environment variables and command line arguments: how they are passed, how are they stored and accessed | * environment variables and command line arguments: how they are passed, how are they stored and accessed | ||
* static versus dynamic linking | * static versus dynamic linking |
Latest revision as of 21:46, 13 December 2012
There's what I would put down. There may be mistakes...
Concepts
- Processes, threads (particularly in terms of execution contexts and address spaces)
Processes are execution environments with a minimum of one running thread. They all have their own virtual memory address spaces. A process can have many threads.
- What code is in the kernel and what isn't
The kernel boots before anything, so it can't rely on any userland libraries like the C std library. The kernel re-implements much functionality found in said library (printf vs printk).
- Supervisor versus user mode
These are CPU modes. Supervisor allows unrestricted access to the system. Only kernel code (with a few exceptions).
User mode only grants access to the system via system calls.
See CPU Modes
- virtualization basics: what is a VM, what does machine look like inside a VM
- Signals (SIGTERM, SIGKILL, SIGSTOP, SIGCONT, SIGCHLD, SIGSEGV, etc.)
- signal handling: what can be handled, who calls them, how do they work?
- Major system calls: fork, execve, open, close, read, write, lseek, mmap
fork: creates a new process and copies the current process image into the newborn execution context
execve: fills the current process with a new an image from a path.
int execve(const char *filename, char *const argv[],char *const envp[]);
open: grants access to file. Returns a file descriptor referring to that file or -1 for errors. Updates OS table of open files.
int open(const char *pathname, int flags, mode_t mode);
close: terminates access to a file. Flushes buffer, free's allocated space, updates metadata and a buncha other cool stuff.
int close(int fd);
read: reads a certain amount of bytes (count) from a file descriptor (fd) to a buffer pointer (*buf)
ssize_t read(int fd, void *buf, size_t count);
write: writes count bytes to a file descriptor fd from buffer pointed at by *buf. Returns number of bytes written, 0 or -1 for errors. Writes after current file offset (see lseek)
ssize_t write(int fd, const void *buf, size_t count);
lseek: reposition read/write file offset
off_t lseek(int fd, off_t offset, int whence);
whence = SEEK_SET SEEK_CUR SEEK_END
mmap: requests a new memory mapping of a given space within the current process's virtual memory address space. Similar to malloc.
see an answer on SO
- The process hierarchy and zombie processes
Basically a tree rooted at init. Every node's parent is its parent process.
Zombie processes are children that have stopped running but haven't been reaped by parents. They still exist on the OS's process table. You get rid of them by killing the parent.
Unix uses terrible metaphors.
- Files, directories, inodes, sparse files
- file permissions: users, groups, others, rwx, where are they stored?
- Basic file-level concurrency, flock
Flock uses a file based mutex. -x means exclusive lock, 200> writes that file on file descriptor 200. The file is located where most locks are... /var/lock/mylockfile.lock
( flock -x 200 ... ) 200> /var/lock/mylockfile.lock
- Ubuntu/Debian alternatives system
Series of symlinks pointed to and from various binaries. Allows you to run multiple versions of binaries (netcat tradition/netcat bsd) and set defaults (www-browser --> links2). The heart of the system lies in /etc/alternatives.
- Basic package management on Ubuntu: apt-get, dpkg
dpkg: installs, keeps track and maintains debian packages.
apt-get: wrapper for dpkg that finds and downloads packages and satisfies dependencies.
- Basic package development: dpkg-dev, dpkg-buildpackage, fakeroot
- filesystem administration: mkfs, fsck, mount, /etc/fstab
- block versus character devices and how they are used
- upstart and init
upstart is init. It controls the boot process and when whatever process gets run. We call these runlevels.
- init and process hierarchy
Init has PID 1
- upstart versus System V init scripts
System V is a few shell scripts being run sequentially, perfect for single core processors from the 90's.
Upstart takes concurrency to heart. Uses dependencies.
- upstart scripts, basic structure, purpose, common options
- SysV init scripts, basic structure and purpose
- device drivers
Code used by the kernel to communicate with hardware. It's an abstraction for the hardware. The kernel creates another abstraction which will be used by users and developers.
- environment variables and command line arguments: how they are passed, how are they stored and accessed
- static versus dynamic linking
- basics of how dynamic linking is implemented (strace-level view)
- strace and ltrace
- Kernel: proc filesystem basics, structure of kernel, relation to C library
- netcat: basic usage
- PATH environment variable and the shell
- basic command line I/O redirection: <, >>, >, |
- shell commands: if, while, for, touch, test (with common tests), echo
- built-in versus external shell commands (and relationship to processes)