A processor privilege level distinguishes user execution from the privileged operating-system kernel. In user state, privileged instructions such as changing page-table control registers, reconfiguring devices or altering protected interrupt controls are forbidden and trap if attempted. Memory accesses are also checked against user-access permissions. Supervisor state permits the kernel to manage these resources; protected transition mechanisms keep user programs from merely setting the privilege bit themselves.
Interrupt masking controls delivery of maskable asynchronous interrupts. Enabled interrupts allow devices and timers to transfer control to the kernel between instructions; disabling them permits short critical operations without those particular interruptions. It does not normally disable synchronous exceptions, faults or nonmaskable interrupts. These two kinds of status bits are independent: privilege determines which instructions and accesses are authorized, whereas the interrupt mask determines which asynchronous events can preempt execution. Privilege protects the machine; interrupt enablement controls asynchronous entry.
A system call or other synchronous trap from user code enters the privileged handler, saving the prior execution status; entry may also mask interrupts depending on the architecture. A device or timer interrupt similarly saves the interrupted context, selects the privileged interrupt handler and commonly adjusts the interrupt mask to control nesting. A return-from-trap or return-from-interrupt instruction restores the saved status, ordinarily returning to user state with interrupts enabled.
These are three distinct transition situations. In addition, the operating-system kernel can explicitly enable or disable interrupts around a critical section using privileged instructions. The exact entry mask is architecture-dependent; entering supervisor state does not logically require interrupts to remain disabled throughout the handler.
Yes: supervisor execution with interrupts enabled is normal and useful. Much of the operating-system kernel can execute with interrupts enabled so that timers, device completions and other urgent events receive prompt service. Disabling them for every potentially long system call would cause excessive latency and could prevent receipt of the very event needed for progress.
Handlers and shared data must then be protected against interrupt-time reentrancy. Disable relevant interrupts only for short critical sequences or use an appropriate synchronization mechanism; on multiple processors, local interrupt masking alone does not protect against another processor. Interrupt enablement and kernel preemption are different: an interrupt can be serviced without allowing an arbitrary process context to preempt the interrupted kernel operation.
In an ordinary general-purpose operating system, untrusted user code should not be allowed to disable the system's timer and device interrupts. Otherwise a nonterminating program could prevent scheduling and device service. User mode is not a reason to permit arbitrary writes to protected interrupt controls.
A restricted trusted environment can nevertheless make this combination useful: a kernel may permit a short, bounded user-level real-time or device operation to run without maskable interrupts, or provide a virtualized per-task interrupt mask which delays that task's notifications while leaving system service active. Such permission must not let an untrusted task disable global service indefinitely. On a uniprocessor a short hardware-masked interval can reduce interruption latency, but it does not prevent faults, nonmaskable interrupts or activity on other cores. Thus the combination is meaningful in controlled cases, not a normal synchronization technique for arbitrary user programs.
An inode is a filesystem object record, identified by its inode number. It contains file type and mode bits, owner/group identifiers, link count, file size, timestamps and the information locating data blocks. It normally does not contain the filename: directory entries map names to inode numbers, allowing several names to refer to one inode. In the traditional Unix layout, there are direct block pointers and single-, double- and triple-indirect pointers. A single-indirect block points to data blocks; a double-indirect block points to single-indirect blocks; the triple-indirect level adds one further pointer layer.
Let be the number of direct pointers. Before triple indirection is needed, the file can use directly addressed data blocks, 512 singly addressed data blocks and doubly addressed data blocks. Indirection blocks consume disk space but are not part of the file's logical byte contents. HenceThe PDF does not specify . With the common twelve-direct-pointer convention, this is bytes; with ten direct pointers, substitute . The formula, rather than an unstated choice of direct-pointer count, determines the answer for the given inode layout. Actual filesystems can use other pointer organizations such as extents.
NTFS offers several capabilities absent from FAT32. Four relevant advantages are per-file security, recoverable metadata updates, larger files and transparent compression. In detail, access control lists and ownership allow different users to have different rights on individual objects; file-system journaling helps recover a consistent metadata structure after a crash; file sizes can exceed FAT32's limit of bytes per file; and built-in compression can reduce the storage needed without changing application file access.
Encryption, quotas and sparse-file support are additional examples, but are not needed for the four requested points. Metadata journaling is not the same as guaranteeing that every recent data write survives a failure, and superiority in these capabilities does not mean universal superiority in compatibility or simplicity. The supported features are compared in the filesystem functionality documentation.
Articles by others on the same topic
There are currently no matching articles.