Operating System Organization - Revision history

Kchan3: /* File Abstraction in Device Management */

2007-10-12T17:35:23Z

File Abstraction in Device Management

← Older revision		Revision as of 17:35, 12 October 2007
Line 8:		Line 8:

	====File Abstraction in Device Management====		====File Abstraction in Device Management====
	In Linux there exists a "/proc" directory which contains special information. This directory does not actually exist on disk. When the kernel receives a request to read a file in one of these directories, it retrieves system information and serves it up as a file. For example, executing more /proc/~~cupinfo~~ gives:		In Linux there exists a "/proc" directory which contains special information. This directory does not actually exist on disk. When the kernel receives a request to read a file in one of these directories, it retrieves system information and serves it up as a file. For example, executing more /proc/cpuinfo gives:

	<pre>		<pre>

Bishopdesmond33: minor typo & grammar fixes

2007-10-01T02:13:42Z

minor typo & grammar fixes

← Older revision		Revision as of 02:13, 1 October 2007
Line 45:		Line 45:
	handle = open(/dev/cdrom, ...)		handle = open(/dev/cdrom, ...)
	</pre>		</pre>
	This is call to the kernel which will use the cd-rom devices drivers to read from the disc.		This is a call to the kernel which will use the cd-rom devices drivers to read from the disc.

	Pipes and sockets both operate as files and support the basic operations		Pipes and sockets both operate as files and support the basic operations:
	* open		* open
	* read		* read

Rgould at 03:25, 24 September 2007

2007-09-24T03:25:22Z

@@ Line 7: / Line 7: @@
 Glenn's talk focused mostly on the how the Linux Kernel works.
-====File Abstraction====
+====File Abstraction in Device Management====
 In Linux there exists a "/proc" directory which contains special information. This directory does not actually exist on disk. When the kernel receives a request to read a file in one of these directories, it retrieves system information and serves it up as a file. For example, executing more /proc/cupinfo gives:
@@ Line 57: / Line 57: @@
 Sockets are used in a similar manner to communicate over a network.
-====Kernel Development====
+===Kernel Development===

Rgould at 03:11, 24 September 2007

2007-09-24T03:11:31Z

@@ Line 24: / Line 24: @@
 Each process that is currently running on the system gets its own directory in /proc, with the process ID (pid) as the directory name. For example for process with pid 2, there exists "/proc/2/" which contains more information about that process.
 The "/dev" directory actually exists on the file system and contains entries for devices (called nodes). For example, the first hard drive on the system might reside in "/dev/hda/". Each device entry has a major node number and a minor node number. For example, the hard drive specified by "/dev/hda" might have major node number "3" and minor node number "0". At first the node numbers were pre-defined and there could be no more than 255 of them. These major/minor node numbers are used to link the specific device types into the kernel. These nodes existed in "/dev" even if the devices were not connected to the system.
-This was eventually replaced with a new system called "devfs" (device file system), which was a pseudo-file system similar to /proc. Devfs is implemented in the kernel and knows about the currently available hardware. Some problems still existed with this system: it was implemented in the kernel, and thus a change to hardware required an update to the kernel; and the major and minor node numbers were still fixed in the kernel. It would be nice to dynamically reassign major nodes to unknown devices that are actually present on the system.
+=====devfs=====
-Devfs has since been replaced by a new system named "udev"
+====Kernel Development====

Rgould at 02:55, 24 September 2007

2007-09-24T02:55:12Z

← Older revision		Revision as of 02:55, 24 September 2007
Line 1:		Line 1:
	~~Notes~~ to be ~~transcribed~~ by ~~Richard Gould.~~		==Operating System Organization==

			===Device Management===

			How do kernels communicate with devices such as a network card? How do drivers for such devices fit into the kernel? We need a mechanism to allow applications to communicate with the devices. Most kernels use a form of message passing, often using a registration system. For example, a network card device driver would register itself with the kernel and identify that it is in fact a network card (as opposed to say, a mouse). MS DOS used interrupt handlers instead.

			Glenn's talk focused mostly on the how the Linux Kernel works.

			====File Abstraction====
			In Linux there exists a "/proc" directory which contains special information. This directory does not actually exist on disk. When the kernel receives a request to read a file in one of these directories, it retrieves system information and serves it up as a file. For example, executing more /proc/cupinfo gives:

			<pre>
			$ more /proc/cpuinfo
			processor : 0
			vendor_id : GenuineIntel
			cpu family : 6
			model : 13
			model name : Intel(R) Pentium(R) M processor 1.73GHz
			stepping : 8
			cpu MHz : 798.000
			cache size : 2048 KB
			...
			</pre>

			Each process that is currently running on the system gets its own directory in /proc, with the process ID (pid) as the directory name. For example for process with pid 2, there exists "/proc/2/" which contains more information about that process.

			The "/dev" directory actually exists on the file system and contains entries for devices (called nodes). For example, the first hard drive on the system might reside in "/dev/hda/". Each device entry has a major node number and a minor node number. For example, the hard drive specified by "/dev/hda" might have major node number "3" and minor node number "0". At first the node numbers were pre-defined and there could be no more than 255 of them. These major/minor node numbers are used to link the specific device types into the kernel. These nodes existed in "/dev" even if the devices were not connected to the system.

			This was eventually replaced with a new system called "devfs" (device file system), which was a pseudo-file system similar to /proc. Devfs is implemented in the kernel and knows about the currently available hardware. Some problems still existed with this system: it was implemented in the kernel, and thus a change to hardware required an update to the kernel; and the major and minor node numbers were still fixed in the kernel. It would be nice to dynamically reassign major nodes to unknown devices that are actually present on the system.

			Devfs has since been replaced by a new system named "udev"

Soma at 19:07, 22 September 2007

2007-09-22T19:07:56Z

New page

Notes to be transcribed by Richard Gould.