100 % Free Calls To Mobile or Landline till 2012

1. Click on this Link
2. Create  and Account and Validate Your Mobile With Verification

Software Testing Techniques

Analysis Modeling

Inter-Process Communication in Linux:

1. Goals:


Linux IPC mechanism is provided so that concurrently executing processes have a means to share resources, synchronize and exchange data with one another. Linux implements all forms of IPC between processes executing on the same system through shared resources, kernel data structures, and wait queues.


Linux provides the following forms of IPC:


Signals: perhaps the oldest form of Unix IPC, signals are asynchronous messages
sent to a process.

Wait queues: provides a mechanism to put processes to sleep while they are waiting for an operation to complete.

File locks: provides a mechanism to allow processes to declare either regions of a file, or the entire file itself, as read-only to all processes except the one which holds the filelock.

Pipes and Named Pipes: allows connection-oriented, bi-directional data transfer between two processes either by explicitly setting up the pipe connection, or communicating through a named pipe residing in the file-system.

System VIPC

Semaphores: an implementation of a classical semaphore model. The model also allows for the creation of arrays of semaphores.

Message queues: a connectionless data-transfer model. A message is a sequence of bytes, with an associated type. Messages are written to message queues, and messages can be obtained by reading from the message queue, possibly restricting which messages are read in by type.

Shared memory: a mechanism by which several processes have access to the same region of physical memory.

Unix Domain sockets: another connection-oriented data-transfer mechanism that provides the same communication model as the INET sockets, discussed in the next section.
2. External Interface:


A signal is a notification sent to a process by kernel or another process. Signals are sent with the send_sig() function. The signal number is provided as a parameter, as well as the destination process. Processes may register to handle signals by using the signal() function.


File locks are supported directly by the Linux file system. To lock an entire file, the open() system call can be used, or the sys_fcntl() system-call can be used. Locking areas within a file is done through the sys_fcntl() system call.


Pipes are created by using the pipe() system call. The file-systems read() and write() calls are then used to transfer data on the pipe. Named pipes are opened using the open() system-call. The System V IPC mechanisms have a common interface, which is the ipc() system call. The various IPC operations are specified using parameters to the system call.


The Unix domain socket functionality is also encapsulated by a single system call, socketcall(). Each of the system-calls mentioned above are well documented, and the reader is encouraged to consult the corresponding man-page.


The IPC subsystem exposes wait calls to other kernel subsystems. Since wait queues are not used by user processes, they do not have a system-call interface. Wait queues are used in implementing semaphores, pipes, and bottom-half handlers. The procedure add_wait_queue() inserts a task into a wait queue. The procedure remove_wait_queue() removes a task from the wait queue.


3. Subsystem Description:


Signals are used to notify a process of an event. A signal has the effect of altering the state of recipient process, depending on the semantics of particular signal. Kernel can send signals to any executing process. A user process may only send a signal to a process or process group if it possesses associated FID or GID. Signals are not handled immediately for dormant processes. Rather, before the scheduler sets a process running in user mode again, it checks if a signal was sent to process. If so, then the scheduler calls the do_signal() function, which handles the signal appropriately.


Wait queues are simply linked lists of pointers to task structures that correspond to processes that are Waiting for a kernel event such as conclusion of a DMA transfer. A process can enter itself on the wait queue by either calling sleep_on() or interruptable_sleep_on() functions. The functions wake_up() and wake_up_interruptable() remove the process from the wait queue. Interrupt routines also use wait-queues to avoid race conditions.


Linux allows user process to prevent other processes to access a file. This exclusion can be based on a whole file or a region of a file. File-locks are used to implement this exclusion. The file-system implementation contains appropriate data: fields in its data structures to allow kernel to determine if a lock has been placed on a file or a region inside a file. In the former case, a lock attempt on a locked file, will fail. In the latter case, an attempt to lock a region already locked will fail. In either case, the requesting process is not permitted to access the file since the lock has not been granted by the kernel.


Pipes and named pipes have a similar implementation, as their functionality is almost the same. The creation of process is different. However, in either case a file descriptor is returned which refers to pipe. Upon creation, one page of memory is associated with opened pipe. This memory is treated like circular buffer to which write operations are done atomically. When the buffer is full, the writing processes block. If a read request is made for more data than available, the reading processes block. Each pipe has a wait queue associated with it. Processes are added and removed from the queue during the read and writes.


Semaphores are implemented with wait queues and follow classical semaphore model. Each semaphore has an associated value. Two operations, up() and down() are implemented on the semaphore. When the value of the semaphore is zero, the process performing the decrement on the semaphore is blocked on the wait queue. Semaphore arrays are simply a contiguous set of semaphores. Each process also maintains a list of semaphore operations it has performed, so that if the process exits prematurely, these operations can be undone.


The message queue is a linear linked-list, to which processes read or write a sequence of bytes. Messages are received in the same order that they are written. Two wait queues are associated with the message queues, one for processes that are writing to a full message queue, and another for serializing the message writes. The actual size of the message is set when the message queue is created.


Shared memory is the fastest form of IPC. This mechanism allows processes to share a region of their memory. Creation of shared memory areas is handled by the memory management system. Shared pages are attached to the user processes virtual memory space by the system call sys_shmat(). A shared page can be removed from the user segment of a process by calling the sys_shmdt() call.


The Unix domain sockets are implemented in a similar fashion to pipes, in the sense that both are based on a circular buffer based on a page of memory. However, sockets provide a separate buffer for each communication direction.


4. Data Structures:


In this section, the important data structures needed to implement the above IPC mechanisms are described.


Signals are implemented through the signal field in the task_struct structure. Each signal is represented by a bit in this field. Thus, the number of signals a version of Linux can support is limited to the number of bits in a word. The field blocked holds the signals that are being blocked by a process.


There is only one data structure associated with wait queues, the wait_queue structure. These structures contain a pointer to the associated task_struct, and are linked into a list.


File locks have an associated file_lock structure. This structure contains a pointer to a task_struct for the owning process, the file descriptor of the locked file, a wait queue for processes which are waiting for the cancellation of the file lock, and which region of the file is locked. The file_lock structures are linked into a list for each open file.


Pipes, both nameless and named,; are represented by a file system inode. This inode stores extra pipe-specific information in the pipe_inode_info structure. This structure contains a wait queue for processes which are blocking on a read or write, a pointer to the page of memory used as the circular buffer for the pipe, the amount of data in the pipe, and the number of processes which are currently reading and writing from/to the pipe.


All system V IPC objects are created in the kernel, and each have associated access permissions. These access permissions are held in the ipc_perm structure. Semaphores are represented with the sem structure, which holds the value of the semaphore and the pid of the process that performed the last operation on the semaphore. Semaphore arrays are represented by the semid_ds structure, which holds the access permissions, the time of the last semaphore operation, a pointer to the first semaphore in the array, and queues on which processes block when performing semaphore operations. The structure sem_undo is used to create a list of semaphore operations performed by a process, so that they can all be undone when the process is killed.


Message queues are based on the msquid_ds structure, which holds management and control information. This structure stores the following fields:

• Access permissions
• Link fields to implement the message queue (i.e. pointers to msquid_ds)
• Times for the last send, receipt and change
• Queues on which processes block, as described in the previous section
• The current number of bytes in the queue
• The number of messages
• The size of the queue (in bytes)
• The process number of the last sender
• The process number of the last receiver.

A message itself is stored in the kernel with a msg structure. This structure holds a link field, to implement a link list of messages, the type of message, the address of the message data, and the length of the message.


The shared memory implementation is based on the shmid_ds structure, which, like the msquid_ds structure, holds management and control information. The structure contains access control permissions, last attach, detach and change times, pids of the creator and last process to call an operation for the shared segment, number of processes to which the shared memory region is attached to, the number of pages which make up the shared memory region, and a field for page table entries.
The Unix domain sockets are based on the socket data structure, described in the Network Interface section.


5. Subsystem Structure:


Control flows from the system call layer down into each module. The System V IPC facilities are implemented in the ipc directory of the kernel source. The kernel IPC module refers to IPC facilities implemented within the kernel directory. Similar conventions hold for the File and Net IPC facilities.


The System V IPC module is dependant on the Kernel IPC mechanism. In particular, semaphores are implemented with wait queues. All other IPC facilities are implemented independently of each other.


6. Subsystem Dependencies:


The IPC subsystem depends on the file system for sockets. Sockets use file descriptors, and once they are opened, they are assigned to an inode. Memory management depends on IPC as the page swapping routine calls the IPC subsystem to perform swapping of shared
memory. IPC depends on memory management primarily for the allocation of buffers and the implementation of shared memory.


Some IPC mechanisms use timers, which are implemented in the process scheduler subsystem. Process, scheduling relies on signals. For these two reasons, the IPC and Process Scheduler modules depend on each other.

Virtual File System in Linux:

1. Goals:


Linux is designed to support many different physical devices. Even for one specific type of device, such as hard drives, there are many interface differences between different hardware vendors. Linux supports a number of logical file systems. It can inter-operate easily with other operating systems. The Linux file system supports the following goals:


Multiple hardware devices: provide access to many different hardware devices.

Multiple logical file systems: support many different logical file systems.

Multiple executable formats: support several different executable file formats (like a out, ELF, Java).

Homogeneity: present a common interface to all of the logical file systems and all hardware devices.

Performance: provide high-speed access to files.

Safety: do not lose or corrupt data.

Security: restrict user access to access files; restrict user total file size with quotas.


2. External Interface:


The file system provides two levels of interface: a system-call interface that is available to user processes, and an internal interface that is used by other kernel subsystems. The system-call interface deals with files and directories. Operations on files include the usual open/close/read/write/seek/tell that are provided by POSIX compliant systems; different types of operations on directories include readdir/creat/unlink/chmod/stat as usual for POSIX systems.


The interface that the file subsystem supports for other kernel subsystems is much richer. The file subsystem exposes data structures and implementation function for direct manipulation by other kernel subsystems. In particular, two interfaces are exposed to the rest of the kernel --- inodes and files. Other implementation details of the file subsystem are also used by other kernel subsystems, but this use is less common.


Inode Interface:


create(): create a file in a directory

lookup(): find a file by name within a directory

link() / symlink() / unlink() / readlink() / follow_link(): manage file system links

mkdir() / rmdir(): create or remove sub-directories

mknod(): create a directory, special file, or regular file

readpage() / writepage(): read or write a page of physical memory to a backing store

truncate(): set the length of a file to zero

permission(): check to see if a user process has permission to execute an operation

smap(): map a logical file block to a physical device sector

bmap(): map a logical file block to a physical device block

rename(): rename a file or directory
In addition to the methods you can call with an inode, the namei() function is provided to allow other kernel subsystems to find the inode associated with a file or directory.


File Interface:


open() / release(): open or close the file

read() / write(): read or write to the file

select(): wait until the file is in a particular state (readable or writeable)

Iseek(): if supported, move to a particular offset in the file

mmap(): map a region of the file into the virtual memory of a user process

fsync() / fasync(): synchronize any memory buffers with the physical device

readdir: read the files that are pointed to by a directory file

ioctl: set file attributes

check_media_change: check to see if a removable media has been removed (such as a floppy)

revalidate: verify that all cached information is valid


3. Subsystem Description:


The file subsystem needs to support many different logical file systems and many different hardware devices. It does this by having two conceptual layers that are easily extended. The device driver layer represents all physical devices with a common interface. The virtual file system layer (VFS) represents all logical file systems with a common interface. The conceptual architecture of Linux kernel shows how this decomposition is conceptually arranged.


Device Drivers:


The device driver layer is responsible for presenting a common interface to all physical devices. Linux kernel has three types of device driver: character, block and network. The two types relevant to file subsystem are character and block devices. Character devices must be accessed sequentially such as 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 file system. This file is referred to as a device special file. Most of kernel deals with devices via file interface, it is easy to add a new device driver by implementing hardware-specific code to support this file interface.


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. Each hardware device has a request queue; when the buffer cache cannot fulfill a request from in-memory buffers, it adds a request to the device's request queue and sleeps until this request has been satisfied. The buffer cache uses a separate kernel thread, kflushd, to write buffer pages out to the devices and remove them from the cache.


When a device driver needs to satisfy a request, it begins by initiating the operation with hardware device manipulating the device's control and status registers (CSR's). There are three general mechanisms for moving data from the main computer to peripheral device: polling, direct memory access (DMA) and interrupts.


When a hardware device wants to report a change in condition (mouse button pushed, key pressed) or to report the completion of an operation, it sends an interrupt to the CPU. If interrupts are enabled, CPU stops executing current instruction and begins executing Linux kernel's interrupt handling code. The kernel finds appropriate interrupt handler to invoke. While an interrupt is being handled, CPU executes in a special context; other interrupts may be delayed until the interrupt is handled. Because of this restriction interrupt handlers need to be quite efficient so that other interrupts are not lost. Sometimes an interrupt handler cannot complete all required work within the time constraints. In this case, the interrupt handler schedules the work in a bottom-half handler. A bottom-half handler is code that is executed by scheduler the next time a system call is completed.


Logical File Systems:


It is possible to access physical devices through device special file. It is more common to access block devices through a logical file system. A logical file system can be mounted at a mount point in virtual file system. It means that the associated block device contains files and structure information that allow logical file system to access the device. At any one time, a physical device can only support one logical file system. However, the device can be reformatted to support a different logical file system.


When a file system is mounted as a subdirectory, all directories and files available on the device are made visible as subdirectories of mount point. Users of virtual file system do not need to be aware what logical file system is implementing which parts of directory tree etc. This abstraction provides a great deal of flexibility in the choice of physical devices and logical file systems. It is one of the essential factors in success of Linux operating system.


Linux uses the concept of inodes to support virtual file system. It uses an inode to represent a file on a block device. The inode is virtual in the sense that it contains operations that are implemented differently depending on logical system and physical system. The inode interface. makes all files appear the same to other Linux subsystems. It is used as a storage location for all of the information related to an open file on disk. It stores associated buffers, total length of file in blocks and the mapping between file offsets and device blocks.


Modules:


Most of the functionality of virtual file system is available in the form of dynamically loaded modules. This dynamic configuration allows Linux users to compile a kernel that is as small as possible, while still allowing it to load required device driver and file system
modules if necessary during a single session. For example, a Linux system might optionally have a printer attached to its parallel port. If printer driver were always linked in to kernel, then memory would be wasted when the printer isn't available. By making the printer driver be a loadable module, Linux allows the user to load the driver if the hardware is available.


4. Data Structures:


The following data structures are architecturally relevant to the file subsystem:


super_block: Each logical file system has an associated superblock used to represent it to the rest of Linux kernel. It contains information about the entire mounted file system.

inode: An inode is an in-memory data structure that represents all of the information that the kernel needs to know about a file on disk. It stores all of the information that the kernel needs to associate with a single file. Accounting, buffering, and memory mapping information are all stored in the inode.

file: The file structure represents a file that is opened by a particular process. All open files are stored in a doubly-linked list. The file-descriptor used in POSIX style routines (open, read, write) is the index of a particular open file in this linked list.


5. Subsystem Structure:


The file system depends on all other kernel subsystems and all other kernel subsystems depend on the file subsystem. In particular, the network subsystem depends on the file system because network sockets are presented to user processes as file descriptors. The memory manager depends on file system to support swapping. The IPC subsystem depends on file system to implement pipes and FIFO's. The process scheduler depends on file system to load modules.


The file system uses the network interface to support NFS. It uses memory manager to implement buffer cache and for a ramdisk device. It uses IPC subsystem to help support modules and it uses process scheduler to put user processes to sleep while hardware requests are completed.

Memory Manager Subsystem in Linux Operating System:

1. Goals:


The memory manager provides the following capabilities to its clients:


Large address space: user programs can reference more memory than physically exists.

Protection: the memory for a process is private and cannot be read or modified by another process; also, the memory manager prevents processes from overwriting code and read-only-data.

Memory Mapping: clients can map a file into an area of virtual memory and access the file as memory.

Fair Access to Physical Memory: the memory manager ensures that processes all have fair access to the machine's memory resources, thus ensuring reasonable system performance.

Shared Memory: the memory manager allows processes to share some portion of their memory. For example, executable code is usually shared amongst processes.


2. External Interface:


The memory manager provides two interfaces to its functionality: a system-call interface that is used by user processes, and an interface that is used by other kernel subsystems to accomplish their tasks.


3. Subsystem Description:


Linux supports several hardware platforms. There is a platform-specific part of the memory manager that abstracts details of all hardware platforms into one common interface. All access to the hardware memory manager is through this abstract interface.


The memory manager uses hardware memory manager to map virtual addresses to physical memory addresses. When a user process accesses a memory location, the hardware memory manager translates virtual memory address to a physical address and then uses the physical address to perform the access. Because of this mapping, user processes are not aware of what physical address is associated with a particular virtual memory address. It allows memory manager subsystem to move process's memory around in physical memory. The mapping also permits two user processes to share, physical memory if regions of their virtual memory address space map to the same physical address space.


The memory manager swaps, process memory out to a paging file when it is not in use. It allows the system to execute processes that use more physical memory than available memory. The memory manager contains a daemon (kswapd). Linux uses the term daemon to refer to kernel threads; a daemon is scheduled by the process scheduler in the same way that user processes are, but daemons can directly access kernel data structures. The concept of a daemon is closer to a thread than a process.


The kswapd daemon periodically checks to see if there are any physical memory pages that have not been referenced recently. These pages are evicted from physical memory. If necessary, they are stored on disk. The memory manager subsystem takes special care, to minimize the amount of disk activity that is required. The memory manager avoids writing pages to disk if they could be retrieved another way.


The hardware memory manager detects when a user process accesses a memory address that is not currently mapped to a physical memory location. The hardware memory manager notifies Linux kernel of this page fault. It is up to memory manager subsystem to resolve the fault. There are two possibilities; either the page is currently swapped out to disk, and must be swapped back in, or the user process is making an invalid reference to a memory address outside of its, mapped memory. The hardware memory manager also detects invalid references to memory addresses such as writing to executable code or executing data. These references also result in page faults that are reported to the memory manager subsystem. If the memory manager detects an invalid memory access, it notifies the user process with a signal; if the process doesn't handle this signal, it is terminated.


4. Data Structures:


The following data structures are relevant:


vm_area: The memory manager stores a data structure with each process that records what regions of virtual memory are mapped to which physical pages. It also stores a set of function pointers that allow it to perform actions on a particular region of the process's virtual memory.

mem_map: The memory manager maintains a data structure for each page of physical memory on system. This data structure contains flags that indicate the status of the page. All page data structures are available in a vector that is initialized at kernel boot time. As page status changes, the attributes in data structure are updated.

free_area: The free_area vector is used to store unallocated physical memory pages; pages are removed from the free_area when allocated, and returned when freed.


5. Subsystem Structure:


The memory manager subsystem is composed of several source code modules; these can be decomposed by areas of responsibility into the following groups.


System Call Interface: This group of modules is responsible to present the services of memory manager to user processes through a well-defined interface.

Memory-Mapped Files (MMAP): This group of modules is responsible for supported memory-mapped file I/O.

Swap file Access (Swap): This group of modules controls memory swapping. These modules initiate page-in and page-out operations.

Core Memory Manager (Core): These modules are responsible for the core memory manager functionality that is used by other kernel subsystems.

Architecture Specific Modules: These modules provide a common interface to all supported hardware platforms. These modules execute commands to change the hardware MMU's virtual memory map, and provide a common means of notifying the rest of the memory-manager subsystem, when a page fault occurs.


6. Subsystem Dependencies:


The memory manager is used directly (via data structures and implementation functions) by each of sched, fs, ipc, and net.

Process Scheduler in Linux Operating System:

1. Goal:


Process scheduling is the heart of Linux operating system. The process scheduler has the following responsibilities:

• Allow processes to create new copies of themselves
• Determine which process will have access to the CPU and effect the transfer between running processes
• Receive interrupts and route them to the appropriate kernel subsystem
• Send signals to user processes
• Manage the timer hardware
• Clean up process resources when a processes finishes executing

The process scheduler also provides support for dynamically loaded modules. These modules represent kernel functionality that can be loaded after kernel has started executing. The loadable module functionality is used by virtual file system and network interface.


2. External Interface:


The process scheduler provides two interfaces. First, it provides a limited system call interface that user processes may call. Secondly, it provides a rich interface to the rest of the kernel system.


Processes can only create other processes by copying the existing process. At boot time, Linux system has only one running process: init. This process then spawns others that can also spawn off copies of themselves through fork () system call. The fork () call generates a new child process that is a copy of its parent. Upon termination, a user process (implicitly or explicitly) calls the _exit () system call.


Several routines are provided to handle loadable modules. A create_module () system call will allocate enough memory to load a module. The call will initialize the module structure, described below, with the name, size, starting address, and initial status for the allocated module. The init_module () system call loads the module from disk and activates it. Finally, delete_module () unloads a running module.


Timer management can be done through the setitimer() and getitimer() routines. The former sets a timer while the latter gets a timer's value.
Among the most important signal functions is signal(). This routine allows a user process to associate a function handler with a particular signal.


3. Subsystem Description:


The process scheduler subsystem is primarily responsible for the loading, execution, and proper termination of user processes. The scheduling algorithm is called at two different
points during the execution of a user process, first, there are system calls that call the scheduler directly, such as sleep(). Second, after every system call, and after every slow system interrupt (described in a moment), the schedule algorithm is called.


Signals can be considered an IPC mechanism, thus are discussed in the inter-process communication section.


Interrupts allow hardware to communicate with the operating system. Linux distinguishes between slow and fast interrupts. A slow interrupt is a typical interrupt. Other interrupts are legal while they are being processed, and once processing has completed on a slow interrupt Linux conducts business as usual, such as calling the scheduling algorithm. A timer interrupt is exemplary of a slow interrupt. A fast interrupt is one that is used for much less complex tasks, such as processing keyboard input. Other interrupts are disabled as they are being processed, unless explicitly enabled by the fast interrupt handler.


The Linux OS uses a timer interrupt to fire off once every 10ms. Thus, according to our scheduler description given above, task rescheduling should occur at lease once every 10ms.


4. Data Structures:


The structure task_struct represents a Linux task. There is a field that represents the process state; this may have the following values:

• Running
• Returning from system call
• Processing an interrupt routine
• Processing a system call
• Ready
• Waiting

In addition, there is a field that indicates the processes priority, and field, which holds the number of clock ticks (10ms intervals), which the process can continue executing without, forced rescheduling. There is also a field that holds the error number of the last faulting system call.


In order to keep track of all executing processes, a doubly linked list is maintained, (through two fields that point to task_struct). Since every process is related to some other process, there are fields which describe a processes: original parent, parent, youngest child, younger sibling, and finally older sibling.


There is a nested structure, mm_struct, which contains a process's memory management information, (such as start and end address of the code segment).


Process ID information is also kept within the task_struct. The process and group id are stored. An array of group id's is provided so that a process can be associated with more than one group. File specific process data is located in a fs_struct substructure. This will hold a pointer to the inode corresponding to a processors root directory, and it's current working directory.


All files opened by a process will be kept track of through a files_struct substructure of the task_struct. Finally, there are fields that hold timing information; for example, the amount of time the process has spent in user mode.


All executing processes have an entry in the process table. The process table is implemented as an array of pointers to task structures. The first entry in the process table is the special init process, which is the first process executed by the Linux system.


Finally, a module structure is implemented to represent the loaded modules. This structure contains fields that are used to implement a list of module structure, a field which points to the modules symbol table, and another field that holds the name of the module. The module size (in pages), and a pointer to the starting memory for the module are also fields within the module structure.


5. Subsystem Structure:


The below figure shows the Process Scheduler subsystem. It is used to represent, collectively, process scheduling and management (i.e. loading and unloading), as well as timer management and module management functionality.






6. Subsystem Dependencies:


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 that are used in bottom-half-handling Finally, the process scheduler depends on the file system to load loadable modules from the persistent device. All subsystems depend on the process scheduler, since they need to suspend user processes while hardware operations complete.

Linux Architecture: Linux Operating System Structure

Linux Kernel participates as one layer in overall system. Linux is composed of five major subsystems within the kernel layer:

• Process Scheduler (sched)
• Memory Manager (mm)
• Virtual File System (vis)
• Network Interface (net)
• Inter-Process Communication (ipc)

Linux Operating System Distributions:

Linux can be freely redistributed. The user can obtain it in a variety of ways. Various individuals and organizations package Linux, often combining it with free or proprietary applications. Such a package that includes all the software needed to install and run Linux is called a Linux distribution.


Caldera, Red Hat, Slackware and SuSE are packaged by commercial companies that get profit by selling Linux-related products and services. The user can download these distributions from the respective companies web sites or make additional copies of a Linux distribution. Debian GNU/Linux is a product of volunteer effort conducted under auspices of Software In The Public Interest, Inc.

Features/Characteristics of Linux Operating System:

Some features of Linux are as follows:


1. Multi-platform:


Linux is a cross-platform operating system. It runs on many computer models.


2. Free:


Linux is free. The user can purchase Linux from a vendor who bundles Linux with special documentation or applications or provides technical support.


3. Open Source:


Linux and many Linux applications are distributed in source form. It makes it possible for others to modify or improve them. That is why Linux is being constantly improved and updated rapidly. It will likely be the first operating system to support Intel's forthcoming Merced 64-bit CPU.


4. Hardware:


Linux can run on almost any hardware such as 386, 486, Pentium MMX, Pentium II, Spare, Dec Alpha or even Motorola 68000 series.


5. Multi-Tasking:


Linux is a multi-tasking system. It means that a single user can run multiple programs at the same time. Each task is called a process. It means that a user can give the system a command to be run in the background while doing more important work in the foreground. This way a user does not have to wait for a process to finish in order to start another one.


6. Multi-User:


Multiuser means that hundreds of people can use the computer at the same time over a network, internet or laptops/computers or terminals connected to serial ports of computers.


7. Multiple Virtual Consoles:


It provides multiple virtual terminals on the server. It can be done by pressing a key combination. In Linux it is Ctrl+Alt+ any of F1 to F6. It brings up different screens to represent separate terminal. It enables different users to login at same time on same machine.


8. TCP/IP Networking:


Linux is one of the best operating systems in terms of networking. TCP/IP is a set of protocols that links millions of university and business computers into a worldwide network known as Internet. With an Ethernet connection, the user can access the Internet or LAN from Linux system. The user can use SLIP (Serial Line Internet Protocol) to access Internet over phone lines with a modem. Linux makes it easy to construct firewalls to protect system.


9. High Level Security:


Linux provides a very high level of security by using user authentication. It also stores passwords in an encrypted form. The password once encrypted cannot be decrypted. Linux also includes file system security that enhances the existing security.


10. GNU Software Support:


Linux supports a wide range of free software written by GNU Project. It includes utilities such as GNU C and C++ compiler, gawk, groff etc. Many essential system utilities used by Linux are GNU software.


11. Virtual Memory and Shared Libraries:


Linux can use a portion of hard drive as virtual memory to expand total amount of available RAM. It also implements shared libraries. It allows programs that use standard subroutines to find the code for these subroutines in libraries at runtime. It saves a large amount of space as each application doesn't store its own copy of common routines.


12. Stable Operating System:


Linux is a complete operating system that is stable. It means that the malfunctioning of an application is not likely to bring the system down.


13. Reliable:


Linux servers are very reliable. They remain up for hundreds of days compared to the regular reboots seen in the case of other operating systems.


14. Web Server:


Linux can be used to run a web server such as Apache to serve application protocols such as HTTP or FTP.


15. Multiple Processor Support:


Linux supports multiple processors. Many companies have hardware that is in danger of becoming obsolete. The capability of adding processors means that these companies will be able to continue using the existing hardware thereby safeguarding their investment.

Introduction to Linux Operating System and History of Linux:


Definition and Explanation/Description:

Linux is another UNIX-like system that has gained popularity in recent years. It has been designed to run as many standard UNIX applications as possible. It has much in common with existing UNIX implementations. Linux is a rapidly evolving operating system.

Brief History of Linux Operating System:

MS DOS was popularly used in the early 1990's by many personal computers. Apple Macs were better but the price was very high. Unix itself was far more expensive. An operating system MINIX was written by Andrew S. Tanenbaum who was a Dutch professor. It was designed to run on Intel 8086 microprocessors. It was not outstanding but its source code was available. Linux Torvalds re-wrote MINIX and created Linux. The Linux operating system-has also been adapted for use in Alpha, Mac, PowerPC and even palmtops.

Software Cost and Effort Estimation in Software Engineering Process

Cause

1. Keyboard is not connected properly.
2. Stuck key
3. Bad keyboard
4. Bad PS/2 or AT port

Solution

Additional information

1. Computer beeps irregularly when the computer is turned on.
2. Computer turns on but does not boot or do anything.
3. Computer reboots every few seconds.

Answer

• All disk drives should have a data cable and power cable connected to them.
• Your power supply should have at least one cable going to the motherboard. Many motherboards may also have additional cables connected to them to supply power to the fans.

1. Re-insert the memory into the same slot.
2. If you have more than one stick of memory remove all but one stick of memory, try rotating through each stick.
3. Try one stick of memory in each slot.

POST troubleshooting steps.

Additional information

1. Computer beeps irregularly when the computer is turned on.
2. Computer turns on but does not boot or do anything.
3. Computer reboots every few seconds.

Answer

• All disk drives should have a data cable and power cable connected to them.
• Your power supply should have at least one cable going to the motherboard. Many motherboards may also have additional cables connected to them to supply power to the fans.

1. Re-insert the memory into the same slot.
2. If you have more than one stick of memory remove all but one stick of memory, try rotating through each stick.
3. Try one stick of memory in each slot.