System Call Practice Questions

When a user-level process receives a SIGINT signal triggered by Ctrl-C, the Unix kernel suspends the current execution flow to facilitate the handling of the signal. The kernel modifies the process's stack and instruction pointer to point to the user-defined signal handler function residing within the process's address space. Since the handler consists of application-level code, the CPU continues executing these instructions with the process's standard privileges. Thus, the signal handler executes in User mode.

The fork() system call duplicates the calling process. In the first iteration ($i=1$), the original process creates $1$ new process, resulting in $2^1$ total processes. In the second iteration ($i=2$), each of the existing $2^1$ processes executes fork(), doubling the total count to $2^2$ processes. Continuing this geometric progression, after $n$ iterations, the total number of processes becomes $2^n$. Since the question asks for the number of new processes created, we subtract the single initial parent process from the total. Thus, the number of new processes is $2^n - 1$.

The mv command is the standard utility for renaming files; thus, mv x y correctly renames file $x$ to $y$ (II). The sequence cp x y creates a copy of $x$ named $y$, and the subsequent rm x deletes the original source file $x$, effectively performing a rename operation (IV). Command I (mv y x) reverses the intended operation, and Command III (cp y x) copies the wrong file source. Consequently, only sequences II and IV accomplish the task of renaming $x$ to $y$.

A system call requires a secure transition from User Mode to Kernel Mode to execute restricted operations. Direct jumps cannot safely change privilege levels, and polling is inefficient for triggering services. Instead, the CPU uses a software interrupt (a trap), such as $\int$ $0x80$ in x86 architectures, to initiate this process. This triggers a hardware-mediated context switch, jumping execution to a predefined address in the Interrupt Descriptor Table ($IDT$) within the kernel. This mechanism ensures that the operating system retains control over protected system resources.

When an interrupt occurs, the CPU transfers control to the OS interrupt handler to manage the specific event. The OS evaluates the cause; if the interrupt indicates an I/O request, the current process state may change to $blocked$ while it waits for resource availability. Consequently, the scheduler may select another process to run, invalidating the claim that the system $always$ resumes the original process (Option C) or $always$ changes its state in a specific way (Option B). Thus, the OS behavior is dynamic, encompassing scenarios where a process is moved to a $blocked$ state and another process is scheduled. This makes Option D the accurate description of OS interrupt management flexibility.