Download operating systems summerizes about system call,types of system calls,system boot and more Summaries Operating Systems in PDF only on Docsity!
User and Operating-System Interface
1.Command Interpreters
2. Graphical User Interfaces
3. Choice of Interface
1.Command Interpreters
- Command Line Interface (CLI) or command interpreter allows direct
command entry Sometimes implemented in kernel, sometimes by systems
program Sometimes multiple flavors implemented – shells
- Primarily fetches a command from user and executes it
- Sometimes commands built-in, sometimes just names of programs If the latter,
adding new features doesn’t require shell modification
On systems with multiple command interpreters to choose from, the interpreters
are known as shells. For example, on UNIX and Linux systems, a user may
choose among several different shells, including the Bourne shell, C shell,
Bourne-Again shell, Korn shell, and others
2. Graphical User Interfaces
- User-friendly desktop metaphor interface
- Usually mouse, keyboard, and monitor
- Icons represent files, programs, actions, etc
- Depending on the mouse pointer’s location, clicking a button on the mouse
can invoke a program, select a file or directory—known as a folder—or pull
down a menu that contains commands
- Various mouse buttons over objects in the interface cause various actions
(provide information, options, execute function, open directory (known as a
folder)
3. Choice of Interface
The choice of whether to use a command-line or GUI interface is mostly one of
personal preference
- Many systems now include both CLI and GUI interfaces Microsoft Windows
is GUI with CLI “command” shell
2.POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X), and 3.Java API for the Java virtual machine (JVM) System Call Implementation
- Typically, a number associated with each system call
- System-call interface maintains a table indexed according to these numbers
- The system call interface invokes intended system call in OS kernel and returns status of the system call and any return values
- The caller need know nothing about how the system call is implemented Just needs to obey API and understand what OS will do as a result call
- Most details of OS interface hidden from programmer by API Managed by run-time support library (set of functions built into libraries included with compiler)
API –– System Call – OS Relationship Fig:The handling of user application invoking the open() system call user application using the open () call to open a file. The open () call invokes the system call interface
There is a system call number corresponding to the open () call.
The system call interface uses this number as an index into the system call table to find the address of the open () routine in the kernel. Using this address, the open () routine in the kernel is now invoked. The open routine in the kernel does whatever is necessary for opening a file and returns a file handle. The file handle (return value) is returned to the user. System Call Parameter Passing Three general methods are used to pass parameters 1.Pass the parameters in Registers: This is fine when there is less number of parameters
2. the parameters can either be stored in a block or table, in memory, and the address of the block- This approach is taken by Linux and Solaris 3.push the parameters onto the stack by the program and the operating system pop off the parameters from the stack.- Both these block and stack methods do not limit the number or length of parameters being passed
- Read, write, reposition
- Get device attributes, set device attributes
- Logically attach or detach devices Information maintenance There are system calls to get or set the time or date of a system, get or set system data, get or set process, file or device attributes.
- Get time or date, set time or date
- Get system data, set system data
- Get process, file or device attributes
- Set process, file or device attributes Communications There are system calls for creating a communication connection with a remote machine and to delete or terminate the connection. There are system calls for sending and receiving messages over a communication connection.
- Create, delete communication connection
- Send, receive messages Protection There are system calls to change the owner of a file, change the group that can access a file, change the access permissions of a file (read permissions, write permissions etc.).
System Programs
At the lowest level is hardware. Next are the operating system, then the system programs, and finally the application programs. System programs provide a convenient environment for program development and execution. Some of them are simply user interfaces to system calls; others are considerably more complex. They can be divided into these categories:
- File management. These programs create, delete, copy, rename, print, dump, list, and generally manipulate files and directories.
- Status information. Some programs simply ask the system for the date, time, amount of available memory or disk space, number of users, or similar status information. Others are more complex, providing detailed performance, logging, and debugging information. Typically, these programs format and print the output to the terminal or other output
Operating-System Debugging
Debugging is the activity of finding and fixing errors in a system, both in hardware and in software. Performance problems are considered bugs, so debugging can also include performance tuning, which seeks to improve performance by removing processing bottlenecks. Failure Analysis If a process fails, most operating systems write the error information to a log file to alert system operators or users that the problem occurred. The operating system can also take a core dump—a capture of the memory of the process— and store it in a file for later analysis. Debuggers allow processes to be executed stepwise, and provide for the examination of variables and expressions as the execution progresses. Debugging user-level process code is a challenge A failure in the kernel is called a crash. When a crash occurs, error information is saved to a log file, and the memory state is saved to a crash dump If the kernel detects an unrecoverable error, it writes the entire contents of memory, or at least the kernel-owned parts of the system memory, to the disk area Instead the kernel crash dump might be saved to a special unallocated portion of the disk reserved for that purpose. Kernighan’s Law Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. Performance Tuning
- Performance tuning ( debottlenecking ) requires monitoring system performance.
- One approach is for the system to record important events into log files, which can then be analyzed by other tools.
- These traces can also be used to evaluate how a proposed new system would perform under the same workload.
- Another approach is to provide utilities that will report system status upon demand, such as the unix "top" command. ( w, uptime, ps, etc. ) System utilities may provide monitoring support.
The Windows Task Manager is a similar tool for Windows systems. The task manager includes information for current applications as well as processes, CPU and memory usage, and networking statistics. DTrace
- DTrace is a special facility for tracing a running OS, developed for Solaris 10.
- DTrace adds "probes" directly into the OS code, which can be queried by "probe consumers".
- DTrace is composed of a compiler, a framework, providers of probes written within that framework, and consumers of those probes.
- Probes are removed when not in use, so the DTrace facility has zero impact on the system when not being used, and a proportional impact in use.
- Consider, for example, the trace of an ioctl system call
operating system in ROM. Storing the operating system in ROM is suitable for small operating systems, simple supporting hardware, and rugged operation. A problem with this approach is that changing the bootstrap code requires changing the ROM hardware chips. Some systems resolve this problem by using erasable programmable readonly memory (EPROM), which is read only except when explicitly given a command to become writable. All forms of ROM are also known as firmware, since their characteristics fall somewhere between those of hardware and those of software. A problem with firmware in general is that executing code there is slower than executing code in RAM. Some systems store the operating system in firmware and copy it to RAM for fast execution. A final issue with firmware is that it is relatively expensive, so usually only small amounts are available. For large operating systems (including most general-purpose operating systems like Windows, Mac OS X, and UNIX) or for systems that change frequently, the bootstrap loader are stored in firmware, and the operating system is on disk. In this case, the bootstrap runs diagnostics and has a bit of code that can read a single block at a fixed location (say block zero) from disk into memory and execute the code from that boot block. The program stored in the boot block may be sophisticated enough to load the entire operating system into memory and begin its execution. More typically, it is simple code (as it fits in a single disk block) and only knows the address on disk and length of the remainder of the bootstrap program. All of the disk-bound bootstrap, and the operating system itself, can be easily changed by writing new versions to disk
