| Course name: | Introduction to Operating Systems |
| Instructor name: | Dr. Aziz Barbar |
This document presents a small introduction/preview for different features of different operating systems which my be running on different CPU architectures.
The covered operating systems are: They are sorted for my preference by the order of their usage and personal familiarity, such as the least used to the most used operating system.
This document is edited and modified by Elias Bachaalany.
This document could have not been written without the great help of a colleague (the name was not disclosed following his request).
Macintosh System Architecture:
Inside the Macintosh, hardware and software work together to provide a system capable of supporting high-performance graphics, built-in peripherals, and communication channels to the outside world. From the beginning of the Macintosh project, the product-design goals of small size, light weight, and moderate end-user cost encouraged us to create a low-power, low component-count design. The large number of I/O devices that are built into each unit, combined with our desire for high performance, caused us to explore many alternatives for each aspect of the hardware implementation. A cooperative spirit among the people working on the industrial design, analog electronics, digital electronics, and low-level software resulted in the synthesis of detailed implementations that combined strengths from each group, providing an integrated design solution for all aspects of the product.
|
|
The heart of the Macintosh digital electronics is the MC68000 processor and its memory (both RAM and ROM). In the Macintosh, the data-output lines from the system RAM drive a data bus separate from that used by the rest of the machine (see figure 2). The RAM is triple-ported; this means that the 68000, screen-displaying hardware, and sound-output hardware have periodic access to the address and data buses, so that the video, the sound, and the current 68000 task appear to execute concurrently.
ROM memory connects directly to the system data bus and is used by only the 68000. Much of the system’s time-critical code, such as the low-level graphics primitives, operating-system routines, and user-interface routines, reside in ROM. Macintosh software calls this code through 68000 “line 1010 unimplemented” instructions, which get one of approximately 480 addresses from an address table stored in low memory; this effectively allows the ROM subroutines to function as extensions of the 68000 instruction set. Since the ROM data and address buses are used exclusively by the 68000, ROM is always accessed at the full processor speed of 7.83 MHz; consequently, the ROM can perform as a read-only cache memory.
The 512- by 342-pixel video display appears in memory as a linear array of 10,944 16-bit words of data, with the most significant bit representing the pixel farthest left. Each 512-pixel horizontal line consists of 32 words of data, with bits shifted out at 15.67 MHz (322.68 µs per 512-pixel line) followed by 12 words of horizontal blanking (taking 12.25 µs). The last memory bus cycle of each horizontal line is reserved for sound DMA, where a byte of sound data is fetched from the sound buffer and sent to the sound PWM (pulse-width modulator) for conversion into an analog level. The update rate of the sound channel is then equal to the video horizontal rate, or 22,254.55 Hz. In the vertical direction, 342 active scan lines are followed by a vertical retrace and enough inactive horizontal lines to take up the same time as 28 horizontal lines, providing a vertical retrace time of 1.258 ms. Although screen-memory accesses may occur at any time, a vertical retrace interrupt is generated at the falling edge of the vertical sync pulse to allow screen animation to occur completely synchronous to the video beam movement.
Access to RAM is divided into synchronous time slots, with the 68000 and video circuits sharing alternate word accesses during the live portion of the horizontal video-display line and the sound circuits using the video time slot during the last memory bus cycle of the horizontal line. Although the access to RAM is divided three ways, the 68000’s share is maximized by giving it access to unused cycles during horizontal and vertical blanking. This way, 68000 access to RAM averages to a speed of about 6 MHz.
For high-performance sound generation, a tightly coded routine generates 370 samples of sound data and places them into the sound buffer just after a vertical retrace interrupt. The 68000’s 32-bit registers are used to control pitch with 24 bits of precision, providing each of four possible voices with 16,777,216 possible frequencies. For simpler sounds, a timer in the system’s VIA provides a square wave of programmable pitch. All sounds pass through a software-controlled.
Windows CE Kernel:
Key components that implements the core functionality of windows CE include:
- Process and thread management
- Predictable thread scheduling
- Memory management
- Interrupt handeling
Borrows the best of windows desktop platforms:
- Uses similar thread, process and virtual memory model
- Windows CE applications run in fully pre-emptive, multitasking environment in protected memory spaces.
Unlike windows for desktops, CE kernel uses DLLs to maximize available memory.
- DLLs written as re-entrant code
- Minimises amount of memory-resident code required to execute applications.
Processes and threads:
Windows CE supports up to 32 simultaneous processes (each process in a single instance of application)
However, each process can have any number of threads (limited only by available memory).
Unit of execution under windows CE is a thread.
Threads operate independently:
- Each one belongs to a particular process(and shares the same memory space, usually 32MB)
- Each thread has an ID, a private 64K stack and a set of registers.
- Together these resources form the context of a thread associated with it upon starting(even of it never explicitly created one)
When threads are stopped from executing by the scheduler (swapped):
- context information is stored
- next thread begins execution
- when original thread resumes execution, context is restored (thread continues to execute here it left off)
Windows CE restricts each process to its own code and data, ex: threads of process A are not allotted to look at or alter any Process’s data.
Processes don’t have any priority! Threads with a process have one of eight priority levels, ranging from THREAD_PRIORITY_TIME_CRITICAL (highest) to THREAD_PRIORITY_IDLE(lowest). On creation threads are assigned a normal priority however this can be changed dynamically.
Threads can run in:
Kernel mode:
Full access to O.S. resources therefore crashes are potentially dangerous to the O.S. itself.
Includes O.S. threads and Interrupt Service Routines (IRSs)
User mode:
Offers protected environment (crashes won’t render the O.S. unusable)
Applications/device drivers run here
Scheduling:
* Priority base, pre-emptive scheduler:
- Runs threads of the same priority in a round-robin fashion
- When there is no thread of a given priority to run, the scheduler uses the next lower level.
(exception is THREAD_PRIROTY_TIME_CRITICAL which runs until completion not interrupted by scheduler)
* Schedule based on threads (not processes)
Ex: 10 threads in a single process and one thread in another – each gets 1/11th of the time slice
* No priority classes like window NT/2000
Threads that normally use their entire allotted time slice:
- can voluntarily give it up by calling Sleep(0) (thread is swapped out and next eligible thread is scheduled instead)
- can wait on availability of resources
What if a low-priority thread holds a resource required by a high-priority thread?
- problem known as “priority inversion”
- deadlock situation possible
Priority inversion
When a higher priority thread requires
a resource locked by a lower priority thread windows CE temporarily boosts
lower thread’s priority until completion and releases the resource.
Unix Architecture
Typical computer system consists of:
1) Hardware
2) Operating system
3) Applications and utilities
Typical OS includes a user interface or command interpreter, but:
Unix is somewhat unique in that
the command interpreter is not integrated
with the OS but is a separate program
Unix Architecture
Levels of Unix Software:
Unix uses a layer approach of defining
software. Layered approach is the basis for Unix
security. At the lowest level,
the level closest to the hardware, are the basic hardware interface modules.
1) Process scheduling
2) Memory management
3) Interrupt handling
4) Low level device control
5) Disk system management
and data buffering
6) Process synchronization
and inter-process communication (IPC)
Unix Functional Layer Model
Kernel Services Layer:
The next level provides all
the kernel services, mapping between user requests and device
driver actions. The user system call is converted to a kernel
service call that actually performs the requested service:
1) Process creation and termination
2) I/O services
3) File/disk access services
4) Terminal handling services
System Call Interface Layer:
The system call interface
layer converts a process running in user mode to a protected kernel mode process.
This allows the program to invoke protected kernel routines to perform system
functions
User Process Layer:
The uppermost layer consists
of user processes running:
1) Shells
1) Unix
commands
3) Utility
programs
4) User
application programs
User processes:
- Protected from other users.
- Have
no access to Unix kernel routines except through the system call interface
- Cannot directly access kernel
memory space
Kernel vs
User Space
In addition to the software levels, Unix
also features two "rings
of protection" from inadvertent programming errors or malicious attacks
that might damage other user's processes or the kernel's processes and data
structures. The inner protected ring is known as kernel space.
The outer ring is called user space.
User Space
User space
is the area in memory where user processes are run. This consists of memory
starting above the kernel and includes the rest of available memory. This
memory is protected; the system prevents one user from interfering with another.
Only kernel process can access a user process. A process operating in this
memory region is said to be operating in user mode
Kernel Space
Kernel space
is the region of memory where all kernel services are provided via kernel
processes. Any process executing in kernel space is said to be executing in
kernel mode. Kernel space is a privileged area; the user has access
to it only through the system call interface. A user does not
have direct access to either all machine instructions or devices. A kernel
process does have direct access to both. Also, a kernel process
can modify the memory map, an operation frequently required to perform process
scheduling. A user process becomes a kernel process when it
executes
a system call and starts executing kernel code.
Data Flow Between
Kernel and User Space
Since users
and the kernel do not share memory address space, the mechanism for moving
data between them is important. When a system call is executed, the arguments
to the call and the corresponding kernel routine identification are passed
from user space to kernel space. Kernel routine ID is usually passed either
via a hardware machine register or via the stack.
Linux
Introduction:
Now it is time to furnish how architecture
business cycle affects Linux. We try to convey some of the principles of Linux
architectural creation, representation, evaluation, and development along the
way. As architects, keep learning from other best systems like Linux is our
eternal principle. As with most things in life, the more effort you put into
learning Linux, the greater your rewards will be. SAIP tells us that software
architecture is a result of technical, business, and social influences.
Following this way to show how successful Linux is, We'll start by explaining
customers and end users of Linux community, who organized Linux, how to achieve
the important qualities, and the architecture implementation issues in
performing Linux development.
Customers and End
Users: Treating your users as co-developers
Users are wonderful things to have, and not just
because they demonstrate that you're serving a need, that you've done something
right. Properly cultivated, they can become co-developers. Linux is designed
for people using Linux... since Linux developers keep adding new features they
would like all the time. The free availability of source code has meant that
Linux has been adopted by many developers and modified to meet their individual
needs. Consequently, the operating systems that have evolved out of this
environment are more stable and better tested than any commercial software.
Drivers are available for a wide range of
peripherals, some written by manufacturers, most written by enthusiasts. With
these drivers added to the kernel, the user teams keep larger and larger.
And in some sense, Linux even challenges and
attracts Microsoft's desktop users.
Developing
Organization: Linux is well supported
The Linux project was closely associated with the GNU
project from the beginning. The GNU project's source base became an extremely
important resource for the Linux community from which to build a complete
system. As Linux matured, some individuals focused on easing the installation
and usability of Linux systems for new users by creating packages, called
distributions, of the Linux kernel and a reasonably complete set of utilities
that together formed a full operating system.
Many Linux distributions are available such as RedHat, SuSE, Debian,
Slackware, GNOME, YellowDog,
etc. Each has its own advantages and disadvantages; however, they all share the
common kernel and development libraries that distinguish Linux systems from
other operating systems.
Technical Environment: Linux runs on
low-end, cheap hardware platforms
Linux was initially developed for IBM-compatible
PC based on the Intel 80386. Over the years, developers have worked to make
Linux available on other architectures, including Alpha, SPARC, SPARC64
Motorola MC680X0, PowerPC, and IBM System/390, MIPS, MIPS64, Arm (Acorn).
Technically speaking, Linux is a true Unix kernel, although it is not a full Unix operating system, because it does not include all the applications such as File System utilities, windowing systems and graphical desktops, system administrator commands, text editors, compilers, and so on. However, since most of these programs are freely available under the GNU General Public License, they can be easily installed into Linux.
Requirements and qualities
Monolithic Kernel vs.
Microkernel:
Most Unix kernels are
monolithic: each kernel layer is integrated into the whole kernel program and
runs in Kernel Mode on behalf of the current process. In contrast, microkernel
architectures (like Mach, Minix) demand a very small
set of functions from the kernel. Although academic research on operating
systems is oriented toward microkernels, such
operating systems force defined interfaces to be maintained between the
individual components and prevent sophisticated optimizations, and thus are
generally slower than monolithic ones, since the explicit message passing
between the different layers of the operating system has a cost. And the
inter-process communication required inside the microkernel is more extensive
than simple function calls.
Linux, on the other hand, was born on the 'slow'
386 architecture. Exploiting all possible ways of optimizing performance to
give good run-time behavior was a primary consideration. This is one reason why
Linux was implemented in the classical monolithic kernel architecture. Another
important reason is undoubtedly the fact that a microkernel
architecture depends on careful design of the system. As Linux has grown by evolving(from the fun of developing a system), this is
simply not possible.
The Linux kernel is one layer in the architecture
of the entire Linux system, and is conceptually composed of five major
subsystems: the process management, the memory management, the virtual file
system, the network interface, and the device control. These subsystems
interact with each other using function calls and shared data structures.
Performance: Linux is powerful
Large parts of the Linux kernel are time-critical;
so the program code is optimized for good run-time behavior such as the time
required to respond to events or the number of events
processed in some interval of time.
Linux kernel is certainly not in every respect a
good model of structured programming. There are 'magic numbers' (similar to
parameterized components in SAIP) in the program text instead of constant
declarations in header files, inline expanded functions instead of function
calls, goto instructions instead of a simple break,
assembler instructions instead of C code, and many other inelegances. Many of
these distinctive features of unstructured programming, however, were
deliberately included. This kind of code is not easy to read, but it really achieves
the performance.
Availability: Linux is reliable
Reliability is a function of many things,
including engineering, testing and integration. It starts with engineering.
Linux has long been praised for its stability. Many Linux boxes (particularly
in the corporate environment) have been known to run for months and even years
without having to be rebooted. If you choose Linux to run your business, you
run less risk of outages to your system. Briefly, the crash of an application
is much less likely to bring down the operating system under Linux; Linux
servers are often up for hundreds of days compared with the regular reboots
required with a Windows system. Our major is fault tolerance, and we analyzed
the Linux kernel by many different ways. Even though Linux does not use too
much fault tolerance technology it increases this by its architectural styles.
Security: Linux security is
improving substantially
Security is an increasingly important concern in
modern times. Definitely, Linux is within the most secure general purpose
operating systems, and continues to become even more secure. Many people have
had great success in using Linux firewalls to protect Linux, Unix,
and Windows networks from harm. Similarly, Linux makes excellent servers for
web hosting, email, file sharing, and other purposes that have better security
records than the alternative operating systems.
We do believe that Linux security is improving
substantially each year/each month due to improvements in it, increased
awareness by SysAdmins and management, and by
increased availability of information. Linux is also, historically, been less
prone to viruses. After all, it's not really in a hacker’s interest to try to
beat an operating system that was originally made for the public without profit
in mind. It should be the very thing they're supporting!!!
It's hard to hide flaws in open source software.
Linux community ensures that security fixes are dealt with in a timely and
professional manner and will keep everyone honest. For example, we have the
experience on Linux firewall, and the Linux 2.4 net filter subsystem is a
complete rewrite of previous Linux 2.2 packet filtering implementations
including “ipchains” and “ipfwadm”.
“Netfilter” provides a large number of improvements,
and it has now become an even more mature and robust solution for protecting
corporate networks.
One more fact: in May 2002, IBM alone announced a
deal to supply the Air Force, Department of Defense (DoD),
Department of Agriculture, Department of Energy, and Federal Aviation
Administration (FAA) with Linux systems.
Portability: Linux is fully customizable in all its components
It runs on a wide variety of hardware, ranging
from 386/486/Pentium II/III/IV's to more exotic hardware such as Digital Alpha
computers, PowerPCs, and Silicon Graphics workstations, as listed in Section 5.
Almost every system operation eventually maps to a
physical device. With the exception of the processor, memory, and a very few
other entities, any and all device control operations are performed by device
driver that is specific to the device being addressed. The kernel embeds a
device driver for every peripheral present on a system, from the hard drive to
the keyboard and the tape streamer. This aspect of the kernel's functions is
always in my primary interests.
Architecture affects
the factors:
The conceptual architecture of the Linux kernel
has proved its success; essential factors for this success were the provision
for the organization of developers, and the provision for system extensibility.
The Linux kernel architecture was required to support a large number of
independent volunteer developers. This requirement suggested that the system
portions that require the most development -- the hardware device drivers and
the file and network protocols -- be implemented in an extensible fashion. The
Linux architect chose to make these systems be extensible using a data
abstraction technique: each hardware device driver is implemented as a separate
module that supports a common interface. In this way, a single developer can
add a new device driver, with minimal interaction required with other
developers of the Linux kernel. The success of the kernel implementation by a
large number of volunteer developers proves the correctness of this strategy.
In spite of its monolithic foundation, Linux is
not a chaotic collection of program code. Certain less time-critical components
of the kernel are only accessed via accurately defined interfaces. A good
example of this is the Virtual File System(VFS), which
represents an abstract interface to all file-oriented operations. Instead, the
chaos is apparent in the detail. At time-critical points, sections of programs
are often written in 'hand-optimized' C code, making them difficult to follow.
Fortunately, these program sections are, as a rule, very well annotated.
Traditional Unix kernels
are compiled and linked statically. Most modern kernels can dynamically load
and unload some portions of the kernel code (typically, device drivers), which
are usually called modules. Linux's support for
modules is very good, since it is able to automatically load and unload modules
on demand.
The best thing about Linux today is the fanatic
following it commands. Whenever a new piece of hardware is out, Linux kernel is
tweaked to take advantage of it. For example, within weeks after the
introduction of Intel Xeon Microprocessor, Linux kernel was tweaked and was
ready for it. It has also been adapted for use in Alpha, Mac, PowerPC, and even
for palmtops, a feat which is hardly matched by any other operating system. And
it continues its journey into the new millennium, with the same enthusiasm that
started one fine day back in 1991.
Linux is always changing. Development on the Linux
kernel will stop when people are no longer interested in building and enhancing
the Linux kernel. So long as new hardware devices such as video cards are being
created and people come up with other neat improvements to make to Linux,
development work will continue.
In short, the main message of this essay is that
the relationships among Linux business goals, product requirements,
practitioners' experience, architectures, and fielded systems form a cycle with
feedback loops that a business can manage. This cycle makes Linux keep success.
Linux Architectural Styles
Overview:
Linux kernel is monolithic. It is a large, complex
do-it-yourself program, composed of several logically different components(or subsystems). The architectural style of the
Linux kernel is close to Data Abstraction style at the highest level. The
kernel is composed of subsystems that maintain internal representation
consistency by using a specific procedural interface. On the other hand, we see
layered styles for Linux as a whole and within the subsystems of the Linux
kernel.. Strictly speaking, Linux kernel only has one
layer in the architecture, but here we relax this definition of layer.
In Linux architecture, each layer provides a
service to the layer above it and serves to the client below. Benefits of this
style of architecture is that this design supports increasing levels of
abstraction and enhancement as changes to the functionality of one layer
affects at most two others. Linux kernel includes the middle layer kernel
modules and two interface layers system call interface and architecture-dependent
code, which provide interface between the user applications, kernel modules,
and hardware. For instance, the system call interface layer provides an
interface between the virtual file system and the user level programs that need
to access a file system. Similarly, the architecture-dependent interface
provides an interface between the virtual file system and the disk that it must
access. The kernel modules layer conceptually composed of six major subsystems:
the process scheduler, the memory management, the virtual file systems, the
network management, inter-process communication management and the device
drivers. These subsystems interact with each other using procedure calls and
shared data structures.
Connectors:
In large complex systems like Linux, connectors
are key determinants of system properties. The file facade, IPC via shared
memory access, and the process scheduler are three major connectors in Linux
kernel architecture. The file facade is a commonly used abstraction to access
devices and file systems in Linux. In addition to coordination, the facade
performs arbitration of interaction between the application process and
physical file system and adaptation by dispatching calls to various file
systems and device drivers.
Shared memory access connector is a commonly used
IPC mechanism on Unix-like systems. It is structurally composed of a supporting
library of system calls that allow the creation, manipulation, and release of
shared memory. The process scheduler, as a connector, links the operating
system to the application processes, coordinates the processes' access to
system resources, and abstracts the resources in a manner that allows their
easy access, independently of other processes.
Data Flow:
Given the nature of the overall structure of
Linux, control flow is passed from the system call, to the appropriate
subsystem, down to the hardware, and then back up to the system call interface.
However, concurrency issues may allow the control of a process to be
transferred to another during a context switch in either direction. Regardless,
control does not change direction once it is suspended (unless resources are
lost during the suspension).
Regardless of the makeup of the kernel, data flows
from the system call interface requesting a service from the file or process
control subsystem which in turn requests a service(s) from the hardware. The
hardware then provides the service to the kernel and passes data back up
through the kernel to the system call interface.
Data Abstraction:
All subsystems in the kernel rely on some common
resources that are not shown in any subsystem. These include procedures that
all kernel subsystems use to allocate and free memory for the kernel's use,
procedures to print warning or error messages, and system debugging routines.
These resources will not be referred to explicitly since they are assumed
ubiquitously available and used within the kernel layer.
The architectural style at this level resembles
the Data Abstraction style. Each of the depicted subsystems contains state
information that is accessed using a procedural interface, and the subsystems
are each responsible for maintaining the integrity of their managed resources.
Layered System:
File
system
The virtual file system is designed to present a
consistent view of data as stored on hardware devices. It allows the system
administrator to mount any of a set of logical file systems on any physical
device. Logical file systems promote compatibility with other operating system
standards, and permit developers to implement file systems with different
policies. The virtual file system abstracts the details of both physical device
and logical file system, and allows user processes to access files using a
common interface, without necessarily knowing what physical or logical system
the file resides on.
The virtual file system management module has
hierarchical style architecture. The virtual file system manager interacts with
various file system drivers, such as ext2, msdos, nfs, etc., which in turn interact with the device drivers
controlling the actual devices. In addition the virtual file system manager
interacts with every other module. Nearly everything in Linux is treated as a
file and as such the file system is an excellent place to provide a common
interface for user level applications. The virtual file system manager is
dependent on the existence of at least one file system, and these are in turn
dependent on the device drivers. The dependency also holds in reverse.
One of the specific logical file systems is the
network file system (as a client only), which interacts with the network
subsystem, so that this file system accesses files on another machine as if
they were part of the local machine. The memory manager uses the virtual file
system to accomplish memory swapping and memory-mapped I/O. Also, the virtual
file system uses the process scheduler to disable processes while waiting for
hardware requests to complete, and resume them once the request has been
completed. Finally, the system call interface allows user processes to call in
to the virtual file system to store or retrieve data.
Memory Management Module:
The memory manager subsystem is responsible for
controlling process access to the hardware memory resources. The style of the
architecture of the memory management module is a combination of the layered
and hierarchical styles. The four major design elements of the architecture are
the demand pager module, the swapping module, the memory mapper
and the shared virtual memory manger. Memory manager permits multiple processes
to securely share the machine's main memory system. In addition, it supports
virtual memory that allows Linux to support processes that use more memory than
is available in the system. Unused memory is swapped out to persistent storage
using the file system then swapped back in when it is needed. The shared
virtual memory manager module provides an interface to the memory manger and is
responsible for all virtual memory management which includes things like
keeping track of what pages are where, which process own which memory and how
long pages have been in memory and unused. The memory mapper
module is responsible for mapping pages into the shared virtual memory. This
module makes use of the demand pager and swapping modules in two ways. When
memory is required, unused or older pages are swapped out by the swapping
module. The requested pages are then mapped into the shared virtual memory by
the memory mapper in conjunction with the demand
pager. The demand pager and swapping module interact with the virtual file
systems in order to swap memory pages out to the Linux swap space, i.e. disk
and to bring them back in.
The memory manager controls the memory hardware,
and receives a notification from the hardware when a page fault occurs. It
means that there is bi-directional data and control flow between the memory
manager modules and the memory manager hardware. Also, the memory manager uses
the file system to support swapping and memory mapped I/O. This requirement
means that the memory manager needs to make procedure calls to the file system
to store and fetch memory pages from persistent storage. Because the file
system requests cannot be completed immediately, the memory manager needs to
suspend a process until the memory is swapped back in; this requirement causes
the memory manager to make procedure calls into the process scheduler. Also,
since the memory mapping for each process is stored in the process scheduler's
data structures, there is a bi-directional data flow between the memory manager
and the process scheduler.
Process Management Module:
The process scheduler is responsible for switching
system resources between multiple user-level processes while ensuring that
undesirable system states, such as deadlocks and resource starvation, do not
compromise the integrity of the system. Additionally, the scheduler must also
try to optimize the utilization of system resources.
The architecture of the process management module
is very simple layer style with only two main design elements, i.e. the
scheduler and the task queue. The process manager is responsible for managing
the time slicing method used to give each process its share of the CPU time. It
uses the scheduler to determine which process should be run next. The scheduler
uses the task queue to keep track of processes waiting to be run. The process
management module interacts with the file system module, which maintains
process lists. All processes in Linux are represented under the /proc virtual
file system. This allows the file system to be used as a common interface for
applications like ps.
The process scheduler requires the memory manager
to set up the memory mapping when a process is scheduled. Further, the process
scheduler depends on the IPC subsystem for the semaphore queues. In addition,
all of the other kernel subsystems depend on the process scheduler to suspend
and resume processes while waiting for hardware requests to complete. These
dependencies are expressed through procedure calls and access to the shared
task queue. All kernel subsystems read and write the data structure
representing the current task, leading to bi-directional data flow throughout
the system.
In addition to the data and control flow within the
kernel layer, the O/S services layer provides an interface for user processes
to register for timer notification. This corresponds to the implicit invocation
architectural style. This leads to a flow of control from the scheduler to the
user processes. Finally, the scheduler communicates with the CPU to suspend and
resume processes; this leads to a data flow, and a flow of control.
Inter-Process Communication:
This subsystem supports several mechanisms for
process-to-process communication on a single Linux system.
The architecture of IPC module follows the
hierarchical style with the IPC manager using one of many different IPC types
for communications (signals, pipes, shard memory, system V, and sockets). Some
of these communication modules use modules located outside the IPC module. For
example pipe communication makes use of the virtual file system, a common
interface; shared memory communication via shared memory; sockets communication
via the network services management module. Message queue manage allows the IPC
manager to process san monitory messages between processes.
Network Services Module:
The network subsystem allows Linux systems to
connect to other systems over a network. There are a number of possible
hardware devices that are supported, and a number of network protocols that can
be used. The network subsystem abstracts both of these implementation details
so that user processes and other kernel subsystems can access the network
without necessarily knowing what physical devices or protocol is being used.
The network services module follows a very simple
layered architecture style. It provides access to several networking standards
and a variety of network hardware. The network services manager interfaces with
the TCP/IP protocol drivers which in turn interface with the necessary device drivers
required to make use of the attached networking hardware.
The network resource manager also communicates
with the IPC manager in order to provide support for IPC through sockets. The
network subsystem uses the process scheduler to suspend and resume processes
while waiting for hardware requests to complete. In addition, the network
subsystem supplies the virtual file system with the implementation of a logical
file system leading to the virtual file system depending on the network
interface and having data and control flow with it. Thus provides a common
interface for user applications.
Device Drivers:
The device driver layer is responsible for
presenting a common interface to all physical devices such as graphics cards,
network cards, hard disks etc. The Linux kernel has three types of device
driver: character, block, and network. The two types relevant to the file
subsystem are character and block devices. Character devices must be accessed
sequentially; typical examples are tape drives, modems, and mice. Block devices
can be accessed in any order, but can only be read and written to in multiples
of the block size.
Each device can be accessed as though it was a
file in the file system (this file is referred to as a device special file).
Since most of the kernel deals with devices through this file interface, it is
relatively easy to add a new device driver by implementing the
hardware-specific code to support this abstract file interface. The Linux
kernel uses a buffer cache to improve performance when accessing block devices.
All access to block devices occurs through a buffer cache subsystem. The buffer
cache greatly increases system performance by minimizing reads and writes to
hardware devices.
In summary, device drivers hide the details of
manipulating a peripheral's CSR's and the data transfer mechanism for each
device. The buffer cache helps improve system performance by attempting to
satisfy file system requests from in-memory buffers for block devices.
The Windows 2000 Family:
Windows NT has been
with us for almost eight years, and as the product has matured, Microsoft
have added more features in an effort to address users' needs and administrators'
requirements.
With Windows 2000,
they have made considerable enhancements to the product line.
Windows 2000 Professional is the preferred 32bit desktop environment, providing
a combination of Windows 98 usability and Windows NT 4 reliability. New features
include support for power management and plug and play (a great bonus for
portable users) and support for new file system features, including EFS (Encrypted
File System).
Windows 2000
server has been created in three different flavors, each with features
appropriate to the target audience. All share the same core features as Windows
2000 Professional, but then add additional features.
Windows 2000
Server is the standard, entry level server platform providing similar power to
the Windows NT 4 Server product. However, it also includes support for Terminal
Services and Active Directory.
Users requiring
more power should opt for Windows 2000 Advanced Server, similar in power to
Windows NT 4 Enterprise Server. It provides enhanced scalability and clustering
support.
Users who need
System
Architecture:
Windows 2000 supports
programs running in user mode and programs running in kernel mode. All of the
Windows 2000 subsystems and applications run in user mode, and each subsystem
and application runs in its own protected address space.
This layered approach provides reliability, stability and extensibility.
Windows 2000 employs a layered model in the kernel-mode portion of the
operating system. At the lowest layer is the Hardware Abstraction Layer (HAL).
On top of the HAL is the kernel, which is the lowest layer in the executive.
On top of the kernel is the rest of the Windows 2000
executive components. The kernel performs low-level operating
system functions such as thread scheduling and exception and interrupt
handling. The HAL is a layer of platform-specific code that protects the kernel
and the rest of the executive from platform differences - although the
predominant platform has always been Intel based. The HAL manipulates hardware
directly.
The remaining components of the executive provide system services to the
environment subsystems. They interact with each other through a set of
well-defined formal interfaces.
The Windows 2000 operating system architecture is a hybrid architecture that
is comprised of client/server, layered, object-oriented, and symmetric
multiprocessing architecture principles. Although it uses objects to represent
shared system resources, Windows 2000 is not strictly an object-oriented
operating system. The bulk of the code is written in C for both tool
availability and portability, and C does not directly support object-oriented
constructs. Windows 2000 borrows from the features of object-oriented
languages. Its features include 32-bit addressing, virtual memory support,
system security and enhanced system integrity, platform independence, and
built-in modular networking.
Windows 2000 reliability and availability improvements:
The operating system is built upon a layered approach, similar to the UNIX
operating system. One advantage of the layered operating structure is that each
layer of code is given access only to the layer below it (interfaces and data
structures). This structure also allows the operating system to be debugged,
starting at the lowest layer and adding one layer at a time until the whole
system works correctly. Layering also makes it easier to enhance the operating
system; one entire layer can be replaced without affecting other parts of the
operating system.
Windows 2000 is a portable operating system because of two design decisions.
First, the operating system was written in ANSI C, a language that enables
programs to be ported easily to other hardware architectures. Second, all parts
of Windows 2000 that must be written for a specific hardware are
isolated in an area called the Hardware Abstraction Layer (HAL). To move
Windows 2000 to a new hardware platform, developers need to do little more than
recompile the C code for the new hardware and create a new HAL. Designing an OS
around a HAL means that a large portion of the code is exactly the same between
hardware platforms. This also means that only the small slice of code that
interfaces with the computer's hardware needs to be rewritten as Windows 2000
is ported between different processor architectures. Thus, it provides a high
level of portability.
The two modes that Windows 2000 operates in—kernel mode and user mode—are
discussed now.
In this mode, the software is able to access the hardware and system data,
as well as access all other system resources. The kernel mode has the following
components:
·
Executive. Contains
components that implement memory management, process and thread management,
security, I/O, interprocess communication, and other
base operating system services. For the most part, these components interact
with one another in a modular, layered fashion.
·
Microkernel. The
Microkernel's primary functions are to provide multiprocessor synchronization,
thread and interrupt scheduling and dispatching, and trap handling and
exception dispatching. During system startup, it extracts information from the
Registry, such as which device drivers to load and in what order.
·
Hardware Abstraction Layer
(HAL). The HAL is the code associated with Windows 2000 that changes with
the hardware the operating system is being run on. Thus, it becomes compatible
with multiple processor platforms. The HAL manipulates the hardware directly.
·
Device drivers. Device
drivers send and receive load parameters and configuration data from the
Registry.
·
Windowing and graphics system.
This system implements the graphical user interface (GUI).
- http://wiki.cs.uiuc.edu/cs427/Weining+Gu+--try
- http://wiki.cs.uiuc.edu/cs427/Linux+Architectural+Styles
- http://www.spinics.net/linux/
- http://www.kernel.org/
- http://www.informit.com/articles/article.asp?p=21122&redir=1
- http://www.aci.com.pl/mwichary/computerhistory/articles/macintoshbytepreview/systemarchitecture
Some references were omitted due to lack of one source. This information was
extract from various non-professional/personal websites. The information was
then processed in a copy/paste manner to fit the subject.
As the author of this document, I do not claim the ownership of any of the
text above.