Prasathda
Prasathda
SUBJECT CODE:20CS403
TITLE: UNIX
SUBMITTED BY
PRASATH S
727821TUIT114
CASE STUDY – UNIX
ABSTRACT
UNIX is a popular operating system, and is used heavily in a large variety of scientific, engineering, and mission critical
applications. Interest in UNIX has grown substantially high in recent years because of the proliferation of the Linux (a Unix look-
alike) operating system. The following are the uses of the UNIX operating system.UNIX was founded on what could be called a
“small is good” philosophy. The idea is that each program is designed to do one job efficiently. Because UNIX was developed by
different people with different needs it has grown to an operating system that is both flexible and easy to adapt for specific needs.
INTRODUCTION
Unix is a powerful and versatile operating system that has been widely adopted in various industries. In this case study, we
will explore the implementation of Unix in a large enterprise, XYZ Corporation, and examine the benefits and challenges associated
with its adoption.In the late 1960s, General Electric, MIT and Bell Labs commenced a joint project to develop an ambitious multi-
user, multi-tasking OS for mainframe computers known as MULTICS. MULTICS was unsuccessful, but it did motivate Ken
Thompson, who was a researcher at Bell Labs, to write a simple operating system himself. He wrote a simpler version of MULTICS
and called his attempt UNICS (Uniplexed Information and Computing System). To save CPU power and memory, UNICS (finally
shortened to UNIX) used short commands to lessen the space needed to store them and the time needed to decode them - hence
the tradition of short UNIX commands we use today, e.g., ls, cp, rm, mv etc. Ken Thompson then teamed up with Dennis Ritchie,
the creator of the first C compiler in 1973. They rewrote the UNIX kernel in C and released the Fifth Edition of UNIX to universities
in 1974. The Seventh Edition, released in 1978, marked a split in UNIX development int
FEATURES OF UNIX OS
UNIX is one of the most popular OS today because of its abilities like multi-user, multi-tasking environment, stability
and portability. The fundamental features which made UNIX such a phenomenally successful operating systems are:
• Multi-user: More than one user can use the machine at a time supported via terminals (serial or network connection).
• Multi-tasking: More than one program can be run at a time.
• Hierarchical file system: To support file organization and maintenance in a easier manner.
STRUCTURE OF UNIX OS
UNIX is a layered operating system. The innermost layer is the hardware that provides the services for the OS. The
following are the components of the UNIX OS. The Kernel The operating system, referred to in UNIX as the kernel, interacts directly
with the hardware and provides the services to the user programs. These user programs don't need to know anything about the
hardware. They just need to know how to interact with the kernel and it's up to the kernel to provide the desired service. One of
the big appeals of UNIX to programmers has been that most well written user programs are independent of the underlying
hardware, making them readily portable to new systems.
User programs interact with the kernel through a set of standard system calls. These system calls request services to be
provided by the kernel. Such services would include accessing a file: open close, read, write, link, or execute a file; starting or
updating accounting records; changing ownership of a file or directory; changing to a new directory; creating, suspending, or killing
a process; enabling access to hardware devices; and setting limits on system resources. UNIX is a multi-user, multi-tasking
operating system. You can have many users logged into a system simultaneously, each running many programs. It is the kernel’s
job to keep each process and user separate and to regulate access to system hardware, including CPU, memory, disk and other
I/O devices.
Linux is a free open source UNIX OS. Linux is neither pure SYS V nor pure BSD. Instead, it incorporates some features from
each (e.g. SYSV-style startup files but BSD-style file system layout) and plans to conform to a set of IEEE standards called POSIX
(Portable Operating System Interface). You can refer to the MCSL-045 Section – 1 for more details in a tabular form. This tabular
form will give you a clear picture about the developments.
The Shell
The shell is often called a command line shell, since it presents a single prompt for the user. The user types a command; the
shell invokes that command, and then presents the prompt again when the command has finished. This is done on a line-by-line
basis, hence the term “command line”. The shell program provides a method for adapting each user’s setup requirements and
storing this information for re-use. The user interacts with /bin/sh, which interprets each command typed. Internal commands are
handled within the shell (set, unset), external commands are cited as programs (ls, grep, sort, ps). There are a number of different
command line shells (user interfaces).
• Bourne (sh)
• Korn (krn)
• C shell (csh)
In Windows, the command interpreter is based on a graphical user interface. In UNIX, there is a line-orientated command
interpreter. More details related to the shells are provided in MCSL-045, shared memory, ...)
System Utilities
The system utilities are intended to be controlling tools that do a single task exceptionally well (e.g., grep finds text
inside files while wc counts the number of words, lines and bytes inside a file). Users can solve problems by integrating these tools
instead of writing a large monolithic application program. Like other UNIX flavours, Linux's system utilities also embrace server
programs called daemons that offer remote network and administration services (e.g. telnetd provides remote login facilities,
httpd serves web pages).
Application Programs
Some application programs include the emacs editor, gcc (a C compiler), g++ (a C++ compiler), xfig (a drawing package),
latex (a powerful typesetting language). UNIX works very differently.
Rather than having kernel tasks examine the requests of a process, the process itself enters kernel space. This means
that rather than the process waiting “outside” the kernel, it enters the kernel itself (i.e. the process will start executing kernel code
for itself). This may sound like a formula for failure, but the ability of a process to enter kernel space is strictly prohibited (requiring
hardware support).
For example, on x86, a 45 Case study – UNIX process enters kernel space by means of system calls - well known points
that a process must invoke in order to enter the kernel. When a process invokes a system call, the hardware is switched to the
kernel settings. At this point, the process will be executing code from the kernel image. It has full powers to wreak disaster at this
point, unlike when it was in user space. Furthermore, the process is no longer pre-emptible.
PROCESS MANAGEMENT
When the computer is switched on, the first thing it does is to activate resident on the system board in a ROM (read-only
memory) chip. The operating system is not available at this stage so that the computer must “pull itself up by its own bootstraps”.
This procedure is thus often referred to as bootstrapping, also known as cold boot. Then the system initialization takes place. The
system initialization usually involves the following steps. The kernel,
• probes and configures hardware devices. Some devices are usually compiled into the kernel and the kernel has the
ability to autoprobe the hardware and load the appropriate drivers or create the appropriate entries in the /dev directory.
• sets up a number of lists or internal tables in RAM. These are used to keep track of running processes, memory
allocation, open files, etc.
Depending on the UNIX version, the kernel now creates the first UNIX processes. A number of dummy processes
(processes which cannot be killed) are created first to handle crucial system functions. A ps -ef listing on each OS shows will show
you the existing processes. init is the last process created at boot time. It always has a process ID (PID) of 1. init is responsible for
starting all subsequent processes. Consequently, it is the parent process of all (non-dummy) UNIX processes.
Don’t confuse the init process with the system init command. The init command (usually found in /sbin or /usr/sbin) is
used by root to put the system into a specific run level.
All subsequent processes are created by init. For example, one of the processes started by init is inetd, the internet super
daemon. (inetd, in turn, creates many other processes, such as telnetd, on demand.) In the Unix process hierarchy, init is called
the parent process and inetd the child of init. Any process can have any number of children (up to the kernel parameter nproc,
the maximum allowed number of processes). If you kill the parent of a child process, it automatically becomes the child of init.
Each running process has associated with it a process ID or PID. In addition, each process is characterized by its parent’s
PID or PPID. Finally, each process runs at a default system priority (PRI). The smaller the numerical value of the PRI, the higher the
priority and vice versa.
It always has a process ID (PID) of init is responsible for starting all subsequent processes. Consequently, it is the parent
process of all (non-dummy) UNIX processes.
The Context of a Process and Context Switching
The context of a process is essentially a snapshot of its current runtime environment, including its address space, stack
space, etc. At any given time, a process can be in user-mode, kernel-mode, sleeping, waiting on I/O, and so on. The process
scheduling subsystem within the kernel uses a time slice of typically 20ms to rotate among currently running processes. Each
process is given its share of the CPU for 20ms, then left to sleep until its turn again at the CPU. This process of moving processes
in and out of the CPU is called context switching. The kernel makes the operating system appear to be multi-tasking (i.e. running
processes concurrently) via the use of efficient context-switching.
At each context switch, the context of the process to be swapped out of the CPU is saved to RAM. It is restored when the
process is scheduled its share of the CPU again. All this happens very fast, in microseconds. To be more precise, context switching
may occur for a user process when
• a hardware interrupt, bus error, segmentation fault, floating point exception, etc. occurs,
• a process voluntarily goes to sleep waiting for a resource or for some other reason, and
• the kernel preempts the currently running process (i.e. a normal process scheduler event). Context switching for a user
process may occur also between threads of the same process. Extensive context switching is an indication of a CPU bottleneck.
• SIGHUP 1 Hangup
• SIGINT 2 Interrupt
• SIGKILL 9 Kill (cannot be caught or ignore)
• SIGTERM 15 Terminate (termination signal from SIGKILL
MEMORY MANAGEMENT
One of the numerous tasks the UNIX kernel performs while the machine is up is to manage memory. In this section, we explore
relevant terms (such as physical vs. virtual memory) as well as some of the basic concepts behind memory management.
The process handling swapping is called sched (in other UNIX variants, it is sometimes called swapper). It always runs as
process 0. When the free memory falls so far below minfree that pageout is not able to recover memory by page stealing, sched
invokes the syscall sched(). Syscall swapout is then called to free all the memory pages associated with the process chosen for
being swapping out. On a later invocation of sched(), the process may be swapped back in from disk if there is enough memory.
Physical vs. Virtual Memory
UNIX, like other advanced operating systems, allows you to use all of the physical memory installed in your system as
well as area(s) of the disk (called swap space) which have been designated for use by the kernel in case the physical memory is
insufficient for the tasks at hand. Virtual memory is simply the sum of the physical memory (RAM) and the total swap space
assigned by the system administrator at the system installation time.
Virtual Memory (VM) = Physical RAM + Swap space.
Dividing Memory into Pages
The UNIX kernel divides the memory into manageable chunks called pages. A single page of memory is usually 4096 or
8192 bytes (4 or 8KB). Memory pages are laid down contiguously across the physical and the virtual memory.
Cache Memory
Cache Memory With increasing clock speeds for modern CPUs, the disparity between the CPU speed and the access speed
for RAM has grown substantially. Consider the following:
• Typical CPU speed today: 250-500MHz (which translates into 4-2ns clock tick)
• Typical memory access speed (for regular DRAM): 60ns
• Typical disk access speed: 13ms In other words, to get a piece of information from RAM, the CPU has to wait for 15-30
clock cycles, a considerable waste of time. Fortunately, cache RAM has come to the rescue.
The RAM cache is simply a small amount of very fast (and thus expensive) memory which is placed between the CPU and
the (slower) RAM. When the kernel loads a page from RAM for use by the CPU, it also prefetches a number of adjacent pages and
stores them in the cache. Since programs typically use sequential memory access, the next page needed by the CPU can now be
supplied very rapidly from the cache. Updates of the cache are performed using an efficient algorithm which can enable cache hit
rates of nearly 100% (with a 100% hit ratio being the ideal case). CPUs today typically have hierarchical caches. The on-chip cache
(usually called the L1 cache) is small but fast (being on-chip). The secondary cache (usually called the L2 cache) is often not on-
chip (thus a bit slower) and can be quite large; sometimes as big as 16MB for high-end CPUs (obviously, you have to pay a hefty
premium for a cache that size).
When a process starts in UNIX, not all its memory pages are read in from the disk at once. Instead, the kernel loads into
RAM only a few pages at a time. After the CPU digests these, the next page is requested. If it is not found in RAM, a page fault
occurs, signaling the kernel to load the next few pages from disk into RAM. This is called demand paging and is a perfectly normal
system activity in UNIX. (Just so you know, it is possible for you, as a programmer, to read in entire processes if there is enough
memory available to do so.)
The UNIX daemon which performs the paging out operation is called pageout. It is a long running daemon and is created
at boot time. The pageout process cannot be killed. Swapping: Let’s say you start ten heavyweight processes (for example, five
xterms, a couple netscapes, a sendmail, and a couple pines) on an old 486 box running Linux with 16MB of RAM. Basically, you do
not have enough physical RAM to accommodate the text, data, and stack segments of all these processes at once.
Since the kernel cannot find enough RAM to fit things in, it makes use of the available virtual memory by a process known
as swapping. It selects the least busy process and moves it in its entirety (meaning the program's in-RAM text, stack, and data 49
Case study – UNIX segments) to disk. As more RAM becomes available, it swaps the process back in from disk into RAM.
While this use of the virtual memory system makes it possible for you to continue to use the machine, it comes at a very
heavy price. Remember, disks are relatively slower (by the factor of a million) than CPUs and you can feel this disparity rather
severely when the machine is swapping. Swapping is not considered a normal system activity.
It is basically a sign that you need to buy more RAM. The process handling swapping is called sched (in other UNIX
variants, it is sometimes called swapper). It always runs as process 0. When the free memory falls so far below minfree that
pageout is not able to recover memory by page stealing, sched invokes the syscall sched(). Syscall swapout is then called to free
all the memory pages associated with the process chosen for being swapping out. On a later invocation of sched(), the process
may be swapped back in from disk if there is enough memory.
CPU SCHEDULING
CPU scheduling in UNIX is designed to benefit interactive processes. Processes are given small CPU time slices by a priority
algorithm that reduces to round-robin scheduling for CPU-bound jobs. The scheduler on UNIX system belongs to the general class
of operating system schedulers known as round robin with multilevel feedback which means that the kernel allocates the CPU
time to a process for small time slice, pre-empts a process that exceeds its time slice and feed it back into one of several priority
queues. A process may need much iteration through the “feedback loop” before it finishes. When kernel does a context switch
and restores the context of a process, the process resumes execution from the point where it had been suspended.
The more CPU time a process accumulates, the lower (more positive) its priority becomes, and vice versa, so there is
negative feedback in CPU scheduling and it is difficult for a single process to take all the CPU time. Process aging is employed to
prevent starvation.
Older UNIX systems used a one second quantum for the round- robin scheduling. 4.33SD reschedules processes every 0.1
second and recomputes priorities every second. The round-robin scheduling is accomplished by the time-out mechanism, which
tells the clock interrupt driver to call a kernel subroutine after a specified interval; the subroutine to be called in this case causes
the rescheduling and then resubmits a time-out to call itself again.
CONCLUTION:
In conclusion, the implementation of Unix in XYZ Corporation proved to be a transformative step towards achieving a
standardized, scalable, and secure IT infrastructure. The adoption of Unix brought numerous benefits to the organization,
including improved operational efficiency, seamless integration, enhanced security, and cost optimization. By consolidating and
standardizing their IT environment, XYZ Corporation was able to streamline their processes, reduce complexity, and achieve
better resource utilization. The phased implementation approach allowed for careful planning, assessment, and migration of
critical systems and applications, minimizing disruption and ensuring data integrity. Training and support programs played a
crucial role in facilitating the transition, equipping the IT staff and end-users with the necessary skills to effectively utilize Unix.