COMP 3000 2012 Week 4 Notes - Revision history

Vnguyen: /* Interrupts */

2012-09-29T00:33:17Z

Interrupts

← Older revision		Revision as of 00:33, 29 September 2012
Line 92:		Line 92:

	== Interrupts ==		== Interrupts ==
			* Scheduler decides what happens next.
			* Disk, network, user input devices, clock, etc can cause interrupt.
			* When making system calls => generate software interrupt
	* On interrupt:		* On interrupt:
	** save CPU state <- registers to process structure		** save CPU state <- registers to process structure

Vnguyen at 00:31, 29 September 2012

2012-09-29T00:31:03Z

← Older revision		Revision as of 00:31, 29 September 2012
Line 85:		Line 85:
	** supervisor mode		** supervisor mode
	*** kernel runs in this mode		*** kernel runs in this mode

			* A process can be at many different states, such as:
			** running : on CPU and executing
			** ready : ready to run
			** blocked : waiting on I/O

			== Interrupts ==

			* On interrupt:
			** save CPU state <- registers to process structure
			** switch to supervisor mode
			** run interrupt handler (system call dispatcher)
			** return to user space (scheduler will restore the CPU state)

Sdp: merged christian's and simon's notes

2012-09-28T16:12:38Z

merged christian's and simon's notes

← Older revision		Revision as of 16:12, 28 September 2012
Line 1:		Line 1:
	=== Package Management ===		== Package Management ==

	* Two popular ones		* Two popular ones
Line 25:		Line 25:
	Dpkg files are basically tar balls (archives). The same format dating back from the		Dpkg files are basically tar balls (archives). The same format dating back from the
	70's. They contain all the scripts and binaries needed to install the system.		70's. They contain all the scripts and binaries needed to install the system.


	~~== Package Management ==~~

	* on Mac, package management is less of a problem because "applications" are directories containing all the files needed by the program		* on Mac, package management is less of a problem because "applications" are directories containing all the files needed by the program
Line 43:		Line 40:
	*** bzip		*** bzip
	*** competes with gzip		*** competes with gzip
	* linux has a couple of main package managers
	** rpm
	** dpkg
	* package manager		* package manager
	** encodes dependencies		** encodes dependencies

Sdp: created system calls section

2012-09-28T16:11:06Z

created system calls section

← Older revision		Revision as of 16:11, 28 September 2012
Line 82:		Line 82:
	*** ltrace		*** ltrace
	**** watch library calls made by a process		**** watch library calls made by a process

			== System Calls ==

			* strace
			* CPU has two modes
			** user mode
			*** processes run in this mode
			** supervisor mode
			*** kernel runs in this mode

Sdp: added my notes

2012-09-28T16:07:44Z

added my notes

← Older revision		Revision as of 16:07, 28 September 2012
Line 25:		Line 25:
	Dpkg files are basically tar balls (archives). The same format dating back from the		Dpkg files are basically tar balls (archives). The same format dating back from the
	70's. They contain all the scripts and binaries needed to install the system.		70's. They contain all the scripts and binaries needed to install the system.


			== Package Management ==

			* on Mac, package management is less of a problem because "applications" are directories containing all the files needed by the program
			* before package managers, linux used tarballs (X.tar.gz)
			** tar
			*** tape archiver
			*** combines files
			*** no compression
			** cpio
			*** copy I/O
			*** similar to tar
			** gz
			*** gnu zip
			** bz2
			*** bzip
			*** competes with gzip
			* linux has a couple of main package managers
			** rpm
			** dpkg
			* package manager
			** encodes dependencies
			** pre/post installation scripts
			** mostly written in shell scripts
			** NB: can uninstall the shell (BAD IDEA)
			* "metapackage managers"
			** built on top of package managers
			** installs missing dependencies
			** resolves conflicts
			** examples
			*** yum
			*** apt
			*** aptitude
			* kernel
			** runs on the hardware
			* regular applications
			** run as processes on the kernel
			** each has its own virtual address space
			* virtual address space
			** maps a virtual address like 2000 to a physical address in memory
			** elaborate virtual memory mechanism (we'll talk about this later)
			* libraries
			** one copy loaded into memory, shared between running processes
			** breaks the notion of process separation
			* static linked library
			** puts the full library into memory with the program
			** allows complete pocess separation
			** wasteful because many copies of the library will be loaded into memory
			* system caller
			** calls from a process to the kernel
			** can watch this to determine how a process is interacting with the outside world through the kernel
			** tools
			*** strace
			**** watch system calls made by a process
			*** ltrace
			**** watch library calls made by a process

Cdelahou: /* Package Management */

2012-09-26T16:30:47Z

Package Management

← Older revision		Revision as of 16:30, 26 September 2012
Line 2:		Line 2:

	* Two popular ones		* Two popular ones
	## dpkg ---> debian		# dpkg ---> debian
	## rpm ---> redhat		# rpm ---> redhat
	## portage --> gentoo. Compile packages from source		# portage --> gentoo. Compile packages from source

	* Historically, packages distrobuted via compressed archives (filename.tar.gz)		* Historically, packages distrobuted via compressed archives (filename.tar.gz)
Line 16:		Line 16:
	lists of repos and do alot of other things. "They have alot of smarts." Basic		lists of repos and do alot of other things. "They have alot of smarts." Basic
	functionality is done by dpkg/rpm, though. Use yum and apt-get for system upgrades.		functionality is done by dpkg/rpm, though. Use yum and apt-get for system upgrades.


			Package management empowers you to know all the dependencies and files needed for a
			a binary. It allows you absolute control over the binaries in your system.
			* you can strip down linux to the base essentials
			* helps you debug programs not that don't start

			Dpkg files are basically tar balls (archives). The same format dating back from the
			70's. They contain all the scripts and binaries needed to install the system.

Cdelahou: /* Package Management */ added example

2012-09-26T16:19:18Z

Package Management: added example

← Older revision		Revision as of 16:19, 26 September 2012
Line 6:		Line 6:
	## portage --> gentoo. Compile packages from source		## portage --> gentoo. Compile packages from source

	* Historically, packages distrobuted via compressed archives		* Historically, packages distrobuted via compressed archives (filename.tar.gz)
	** Tar --> archives uncompressed		** Tar --> archives uncompressed
	** .gz, .bz2 --> compression		** .gz, .bz2 --> compression

Cdelahou: first draft notes

2012-09-26T16:18:51Z

first draft notes

New page

=== Package Management ===

* Two popular ones
## dpkg ---> debian
## rpm ---> redhat
## portage --> gentoo. Compile packages from source

* Historically, packages distrobuted via compressed archives
** Tar --> archives uncompressed
** .gz, .bz2 --> compression
* This method does not take into consideration dependencies, -pre&post install scripts

Package management's true innovation was that it handled all this.

Yum, apt-get, aptitude are wrappers built around rpm and dpkg. These also maintain
lists of repos and do alot of other things. "They have alot of smarts." Basic
functionality is done by dpkg/rpm, though. Use yum and apt-get for system upgrades.