System   Structures:
Quizzes   from   the   System   structures
Notes   from   the   System   Strutures   (Entering   and   Existing   the   Kernel)
Questions   below   that   are   roughly   discussed   in   the   classes.
Question: The services and functions provided by an operating system can be divided into two main categories. Briefly describe the two categories and discuss how they differ.
Answer: One class of services provided by an operating system is to enforce protection between different processes running concurrently in the system. Processes are allowed to access only those memory locations that are associated with their address spaces. Also, processes are not allowed to corrupt files associated with other users. A process is also not allowed to access devices directly without operating system intervention.
The second class of services provided by an operating system is to provide new functionality that is not supported directly by the underlying hardware. Virtual memory and file systems are two such
examples of new services provided by an operating system.
Question:   Describe   three   general   methods   for   passing   parameters   to   the   operating   system.
Answer: a. Pass parameters in registers b. Registers pass starting addresses of blocks of parameters c. Parameters can he placed, or pushed, onto the stack by the program, and popped off the stack by the operating system.

Question   3:
What are the advantages and disadvantages of using the same system- call interface for manipulating both files and devices?
Answer: Each device can be accessed as though it was a file in the file system. 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. Therefore, this benefits the development of both user program code, which can be written to access devices and files in the same manner, and device driver code, which can be written to support a well-defined API. The disadvantage with using the same interface is that it might be difficult to capture the functionality of certain devices within the context of the file access API, thereby either resulting in a loss of functionality or a loss of performance. Some of this could be overcome by the use of ioctl opera ation that provides a general
purpose interface for processes to invoke operations on devices.
Question: What is the purpose of the command interpreter? Why is it usually separate from the kernel? Would it be possible for the user to develop a new command interpreter using the system-call interface provided by the operating system?
Answer: It reads commands from the user or from a file of commands and executes them, usually, by turning them into one or more system calls. It is usually not part of the kernel since the Command interpreter is subject to changes. A user should be able to develop a new command interpreter using the system-call interface provided by the operating system. The command interpreter allows a user to create and manage processes and also determine ways by which they communicate (such as through pipes and files). As all of this functionality could be accessed by an user-level program using the system calls, it should be possible for the user to develop a new commandline interpreter.
Question: why does Java provide the ability to call from a Java program native methods that are written in, say, C or C++? Provide an example of a situation in which a native method is useful.

Answer: Java programs are intended to be platform I/O independent.
Therefore, the laniuage does not provide access to most specific system resources such as reading from I/O devices or ports. To perform a system I/O specific operation, you must write it in a language that supports such features (such as C or C++.) Keep in mind that a Java program that calls a native method written in another language ill no longer he architecture-neutral.
Question : What are the three most available APIS for OS?
Three of the most common APIs available to application programmers arc the win32 API for windows systems, the POSIX API for POSIX-based systems (which includes virtually ali versions of UNIx, Linux, and Mac Os x), and the Java API for designing programs that run on the Java virtual machine.
Question: What system calls have to be executed by a command interpreter or shell in order to start a new process?
Answer: In Unix systems, fork system call followed by an exec system call need to be performed to start a new process. The fork call clones the currently executing process, while the exec call overlays a new process based on a different executable over the calling process.
Question: why would an application Programmer prefer Programming according to an API rather than invoking actual system calls?
Answer: There are several reasons for doing so. One benefit of programming according to an API concerns program portability: An application programmer designing a program using an API can expect her program to compile and run on any system tiat supports the same APi (although in reality, architectural differences often make this more difficult than it may appear). Furthermore, actual system calls can often be more detailed and difficult to work with than the API available to an application programmer. Regardless, there often exists a strong correlation between invoking a function in the API and its associated system call within the

kernel. In fact, many of the POSIX and Win32 APIs are similar to the native system calls provided by the UNIX, Linux, and Windows operating systems.
Question: What is the benefit of viewing a system such as operating system as a set of layers? Why shouldn’t an operating system be build as one large program?
Ans: Operating system provides the user with a higher-level way to control the underlying hardware of the machine.
For example: Using the high-level read (ft, buf, b) system call to read a byte from the hard disk which the OS translates to the low-level assembly language sequence to set up and perform the disk transfer.
Viewing the operating system as a set of layers has the following advantages. z
Easier to understand OS. Presents an ordered view of an OS. z Easy to improve OS by modifying a layer. Layers are assumed independent in operation with well-defined interfaces. Layering is an example of software modularity. z
Possibility on standardization of different layers. z Different teams can be responsible for software development of different layers. z Easy to debug and maintain OS. Makes it possible to develop sophisticated
systems.
On the other hand, a monolithic OS has the following problems: z Very large intricate source. A nightmare to program and maintain. z Not easy to develop OS as a team: can’t allocate programming task
What are the System calls in operating system? How it is different from a procedure call? Mention some system calls with short description.

Ans:    System   call   is   a   subroutine   which   internally   interacts   with   the   kernel   which   is   operated   by   the   os.
Function   is   a   sub   program   which   is   going   to   return   a   value.
System calls are provided by the system and are executed in the system kernel.
They are entry points into the kernel and are therefore NOT linked into your program. These are not portable calls. Library calls include the ANSI C standard library and are therefore portable. These functions are linked into your program.
It is worth noting that, because system calls are part of the O/S. The program has to make a context switch to the kernel when they are called and because of this, they have a high startup overhead. The upside is that the time executing these routines is assigned to the OS and not the user program.
From an implementor's point of view, the distinction between a system call and a library function is fundamental. But from a user's perspective, the difference is not as critical. From our perspective in this text, both system calls and library functions appear as normal C functions. Both exist to provide services for application programs. We should realize, however, that we can replace the library functions, if desired, whereas the system calls usually cannot be replaced.
Consider the memory allocation function malloc as an example. There are many ways to do memory allocation and its associated garbage collection (best fit, first fit, and so on). No single technique is optimal for all programs. The UNIX system call that handles memory allocation, sbrk(2), is not a general-purpose memory manager. It increases or decreases the address space of the process by a specified number of bytes. How that space is managed is up to the process. The memory allocation function, malloc(3), implements one particular type of allocation. If we don't like its operation, we can define our own malloc function, which will probably use the sbrk system call. In fact, numerous software packages implement their own memory allocation algorithms with the sbrk system call. Figure 1.11

shows the relationship between the application, the malloc function, and the sbrk system call.
Here we have a clean separation of duties: the system call in the kernel allocates an additional chunk of space on behalf of the process. The malloc library function manages this space from user level.
Another example to illustrate the difference between a system call and a library function is the interface the UNIX System provides to determine the current time and date. Some operating systems provide one system call to return the time and another to return the date. Any special handling, such as the switch to or from daylight saving time, is handled by the kernel or requires human intervention. The
UNIX System, on the other hand, provides a single system call that returns the number of seconds since the Epoch: midnight, January 1, 1970, Coordinated
Universal Time. Any interpretation of this value, such as converting it to a humanreadable time and date using the local time zone, is left to the user process. The standard C library provides routines to handle most cases. These library routines handle such details as the various algorithms for daylight saving time.
An application can call either a system call or a library routine. Also realize that many library routines invoke a system call.
Another difference between system calls and library functions is that system calls usually provide a minimal interface, whereas library functions often provide more elaborate functionality. We've seen this already in the difference between the sbrk system call and the malloc library function. We'll see this difference later, when we compare the unbuffered I/O functions ( Chapter 3 ) and the standard I/O functions
( Chapter 5 ).

The process control system calls (fork, exec, and wait) are usually invoked by the user's application code directly. (Recall the bare-bones shell in Figure 1.7
.) But some library routines exist to simplify certain common cases: the system and popen library routines, for example. In Section 8.13
, we'll show an implementation of the system function that invokes the basic process control system calls. We'll enhance this example in Section 10.18
to handle signals correctly.
To define the interface to the UNIX System that most programmers use, we have to describe both the system calls and some of the library functions. If we described only the sbrk system call, for example, we would skip the more programmerfriendly malloc library function that many applications use. In this text, we'll use the term function to refer to both system calls and library functions, except when the distinction is necessary.
What is the purpose of system calls?
Answer: System calls allow user-level processes to request services of the operating system.
What are the five major activities of an operating system in regard to process management?
Answer: a. The creation and deletion of both user and system processes b. The suspension and resumption of processes c. The provision of mechanisms for process synchronization
d. The provision of mechanisms for process communication e. The provision of mechanisms for deadlock handling
Question: List five services provided by an operating system that are designed make it more convenient for users to use the computer system. In wi cases it would be impossible for user-level programs to provide thi services?
Explain.

Answer:
• Program execution. The operating system loads the contents (or sections) of a file into memory and begins its execution. A user-level program could not be trusted to properly allocate CPU time.
• I/O operations. Disks, tapes, serial lines, and other devices must be communicated with at a very low level. The user need only specify the device and the operation to perform on it, while the system converts that request into device- or controller-specific commands. User-level programs cannot be trusted to only access devices they should have access to and to only access them when they are otherwise unused.
•
File-system manipulation. There are many details in file creation, deletion, allocation, and naming that users should not have to perform.
Blocks of disk space are used by files and must be tracked. Deleting a file requires removing the name file information and freeing the allocated blocks. Protections must also be checked to assure proper file access. User programs could neither ensure adherence to protection
methods nor be trusted to allocate only free blocks and de allocate blocks on file deletion.
•
Communications. Message passing between systems requires messages be turned into packets of information, sent to the network controller, transmitted across a communications medium, and reassembled by the destination system. Packet ordering and data correction must take place.
Again, user programs might not coordinate access to the network device, or
they might receive packets destined for other processes.
•
Error detection. Error detection occurs at both the hardware and software levels.
At the hardware level, all data transfers must be inspected to ensure that data have not been corrupted in transit. All data on media must be checked to be sure they have not changed since they were written to the media. At the software level, media must be checked for data consistency: for instance, do the numbers of allocated and unallocated blocks of storage match the total number on the device. There, errors are frequently Process-independent (for instance, the

corruption of data on a disk), so there must be a global program (the operating system) that handles all types of errors. Also, by having errors processed by the operating system, processes need not contain code to catch and correct all the errors possible on a system.