6c:T44c,#include #include #include int main() { // ===== Using stdio (FILE streams) ===== FILE *fp = fopen("/tmp/test.txt", "w"); if (fp) { // Each fprintf() may just update the buffer, not call write() for (int i = 0; i < 1000; i++) { fprintf(fp, "Line %d ", i); // Buffered! } // fclose() flushes buffer and calls close() fclose(fp); } // ===== Using raw system calls ===== int fd = open("/tmp/test2.txt", O_WRONLY | O_CREAT | O_TRUNC, 0644); if (fd != -1) { char buf[32]; // Each iteration makes a system call - SLOW! for (int i = 0; i < 1000; i++) { int len = snprintf(buf, sizeof(buf), "Line %d ", i); write(fd, buf, len); // System call every time! } close(fd); } return 0; } /* * Performance comparison (typical results): * * stdio version: ~2-5 system calls (buffered) * syscall version: 1000 system calls (unbuffered) * * The stdio version is often 10-100x faster for many small writes! */6d:T6a6,#include #include #include /* * Demonstrate system call overhead by comparing: * 1. A trivial computation (no syscall) * 2. getpid() - one of the simplest possible syscalls */ #define ITERATIONS 1000000 int main() { struct timeval start, end; long elapsed_usec; // Measure trivial computation gettimeofday(&start, NULL); volatile int sum = 0; for (int i = 0; i < ITERATIONS; i++) { sum += i; // No syscall } gettimeofday(&end, NULL); elapsed_usec = (end.tv_sec - start.tv_sec) * 1000000 + (end.tv_usec - start.tv_usec); printf("Trivial computation: %ld µs for %d iterations ", elapsed_usec, ITERATIONS); printf(" Per iteration: %.2f ns ", (elapsed_usec * 1000.0) / ITERATIONS); // Measure getpid() syscall gettimeofday(&start, NULL); for (int i = 0; i < ITERATIONS; i++) { getpid(); // Simple syscall } gettimeofday(&end, NULL); elapsed_usec = (end.tv_sec - start.tv_sec) * 1000000 + (end.tv_usec - start.tv_usec); printf(" getpid() syscall: %ld µs for %d iterations ", elapsed_usec, ITERATIONS); printf(" Per syscall: %.2f ns ", (elapsed_usec * 1000.0) / ITERATIONS); return 0; } /* * Typical output on modern Linux (x86_64): * * Trivial computation: 2847 µs for 1000000 iterations * Per iteration: 2.85 ns * * getpid() syscall: 156234 µs for 1000000 iterations * Per syscall: 156.23 ns * * Note: getpid() is often cached in userspace via vDSO, * making it faster than most syscalls. Real I/O syscalls * are typically 10-100x slower. */6e:T40c,#include #include #include #include #include int main() { int fd = open("/nonexistent/file.txt", O_RDONLY); if (fd == -1) { // errno is set by the failed system call printf("Error code: %d ", errno); printf("Error string: %s ", strerror(errno)); // Or use perror() for combined message perror("open() failed"); // Handle specific errors differently switch (errno) { case ENOENT: printf("File or directory not found "); break; case EACCES: printf("Permission denied "); break; case EMFILE: printf("Too many open files in process "); break; case ENFILE: printf("Too many open files in system "); break; default: printf("Unexpected error "); } } return (fd == -1) ? 1 : 0; }65:{"json":{"id":"seed_e4da67cbbdbd7b057526bc36bdccb4ea","slug":"io-software-layers","category":"Operating Systems","topic":"I/O Software Layers","title":"I/O Software Layers","description":"Explore the complete I/O software stack from user-level applications through device-independent software, device drivers, interrupt handlers, down to the hardware layer. Understand how each layer abstracts complexity and provides essential services for input/output operations.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_8f4b56fa87bf08818481b457c1128dbd","title":"User-Level I/O","order":0,"content":[{"id":"opening-hook","title":"The Gateway to the Outside World","content":[{"data":{"content":"Every program that reads from a file, writes to disk, communicates over a network, or interacts with any external device does so through **I/O operations**. Yet from the programmer's perspective, these operations appear deceptively simple: a `read()` here, a `write()` there, perhaps a `printf()` to display results. This apparent simplicity masks an intricate hierarchy of software layers, each performing crucial transformations as data flows between your application and physical hardware.\n\nThe **User-Level I/O layer** sits at the apex of this hierarchy—the boundary where application code meets operating system services. Understanding this layer is essential for any systems programmer, as it determines performance characteristics, portability, and the fundamental patterns of how programs interact with the outside world."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete user-level I/O architecture: how applications request I/O services, the role of C library abstractions, the difference between buffered and unbuffered I/O, the anatomy of I/O system calls, and how requests flow from user space to the kernel boundary. You'll gain insight into design decisions that affect performance and reliability in real-world systems.","variant":"info"},"type":"callout"}]},{"id":"io-software-stack-overview","title":"The I/O Software Stack Overview","content":[{"data":{"content":"Before diving into user-level I/O specifically, let's establish context by examining the complete I/O software stack. Modern operating systems organize I/O functionality into **five distinct layers**, each with specific responsibilities:\n\n1. **User-Level I/O Software** — Applications and libraries that request I/O services\n2. **Device-Independent I/O Software** — Common I/O functionality shared across all devices\n3. **Device Drivers** — Device-specific code that translates generic requests to hardware commands\n4. **Interrupt Handlers** — Low-level code that responds to hardware interrupts\n5. **Hardware** — Physical I/O devices and their controllers\n\nThis layered architecture embodies the principle of **abstraction**: each layer presents a simplified interface to the layer above while hiding implementation complexity. The user-level layer is where we begin our journey."},"type":"text"},{"data":{"height":"500px","mermaidSyntax":"flowchart TB\n subgraph UserSpace[\"User Space\"]\n App[\"Application Program\nwrite(fd, buffer, size)\"]\n CLib[\"C Library (libc)\nBuffering, Formatting\"]\n end\n \n subgraph KernelSpace[\"Kernel Space\"]\n DI[\"Device-Independent Software\nNaming, Protection, Buffering\"]\n DD[\"Device Drivers\nDevice-Specific Translation\"]\n IH[\"Interrupt Handlers\nHardware Event Response\"]\n end\n \n subgraph Hardware[\"Hardware Layer\"]\n DC[\"Device Controller\nControl Registers, Data Buffers\"]\n Dev[\"Physical Device\nDisk, Network, Terminal\"]\n end\n \n App --> CLib\n CLib -->|\"System Call\"| DI\n DI --> DD\n DD --> IH\n IH <--> DC\n DC <--> Dev\n \n style UserSpace fill:#e8f5e9,stroke:#2e7d32\n style KernelSpace fill:#e3f2fd,stroke:#1565c0\n style Hardware fill:#fff3e0,stroke:#ef6c00"},"type":"mermaid-excalidraw"},{"data":{"content":"**Why this layering matters:**\n\nThe layered approach provides several critical benefits:\n\n- **Portability**: Applications use standardized interfaces regardless of underlying hardware\n- **Maintainability**: Changes to one layer don't ripple through the entire stack\n- **Modularity**: New devices can be added by writing only device-specific code\n- **Security**: The kernel enforces access control at the boundary between user and kernel space\n\nThe user-level layer is particularly important because it's where **programmers spend most of their time**. The decisions made at this level—choice of I/O APIs, buffering strategies, synchronous vs asynchronous patterns—directly impact application performance and behavior."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"io-system-calls","title":"I/O System Calls: The Kernel Interface","content":[{"data":{"content":"At the heart of user-level I/O are **system calls**—the mechanism by which user-space programs request services from the operating system kernel. For I/O operations, the kernel provides a set of primitive operations that form the foundation of all higher-level I/O functionality.\n\n**The Core I/O System Calls:**\n\nIn Unix-like systems, the fundamental I/O system calls are remarkably elegant in their simplicity:"},"type":"text"},{"data":{"rows":[["`open()`","Open or create a file","pathname, flags, mode","File descriptor (int) or -1 on error"],["`close()`","Close an open file descriptor","fd","0 on success, -1 on error"],["`read()`","Read bytes from a file descriptor","fd, buffer, count","Bytes read, 0 at EOF, -1 on error"],["`write()`","Write bytes to a file descriptor","fd, buffer, count","Bytes written, -1 on error"],["`lseek()`","Reposition file offset","fd, offset, whence","New offset, -1 on error"],["`ioctl()`","Device-specific control operations","fd, request, argp","Request-dependent"]],"caption":"Fundamental Unix I/O System Calls","headers":["System Call","Purpose","Key Parameters","Return Value"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"The File Descriptor Abstraction","content":"A **file descriptor** is a small non-negative integer that the kernel uses to identify an open file (or other I/O resource) within a process. This simple integer serves as a handle for all subsequent I/O operations, abstracting away the complexity of internal kernel data structures that track file state, position, and access modes.","variant":"tip"},"type":"callout"},{"data":{"content":"**Anatomy of a read() System Call:**\n\nLet's trace what happens when a program executes `read(fd, buffer, 1024)`:"},"type":"text"},{"data":{"fileName":"read_example.c","languages":[{"code":"#include \n#include \n#include \n\nint main() {\n char buffer[1024];\n ssize_t bytes_read;\n \n // open() returns a file descriptor\n int fd = open(\"/etc/passwd\", O_RDONLY);\n if (fd == -1) {\n perror(\"open failed\");\n return 1;\n }\n \n // read() copies bytes from kernel buffer to user buffer\n // The kernel may:\n // 1. Return data from cache (fast path)\n // 2. Block waiting for disk I/O (slow path)\n // 3. Return less than requested (short read)\n bytes_read = read(fd, buffer, sizeof(buffer));\n \n if (bytes_read == -1) {\n perror(\"read failed\");\n close(fd);\n return 1;\n }\n \n printf(\"Read %zd bytes\n\", bytes_read);\n \n // Always close file descriptors to release resources\n close(fd);\n return 0;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**The System Call Mechanism:**\n\nSystem calls are fundamentally different from regular function calls. When a program invokes a system call:\n\n1. **Trap to Kernel Mode**: The CPU executes a special instruction (e.g., `syscall` on x86-64) that switches from user mode to kernel mode\n2. **Parameter Validation**: The kernel validates all parameters—especially pointers, which must reference valid user-space memory\n3. **Privilege Elevation**: The kernel code executes with full hardware privileges\n4. **Service Execution**: The requested operation is performed (potentially involving hardware and blocking)\n5. **Return to User Mode**: Results are copied to user buffers and control returns to user space\n\nThis mode switch is expensive—typically **hundreds to thousands of CPU cycles**—which is why minimizing system calls is crucial for performance."},"type":"text"},{"data":{"height":"450px","mermaidSyntax":"sequenceDiagram\n participant App as Application\n participant CPU as CPU (User Mode)\n participant Kernel as Kernel (Kernel Mode)\n participant Hardware as Hardware\n\n App->>CPU: read(fd, buf, n)\n CPU->>CPU: syscall instruction\n Note over CPU: Mode switch to kernel\n CPU->>Kernel: Handle syscall #0 (read)\n Kernel->>Kernel: Validate fd, buffer pointer\n Kernel->>Kernel: Check file permissions\n \n alt Data in page cache\n Kernel->>Kernel: Copy from cache to user buffer\n else Cache miss\n Kernel->>Hardware: Initiate disk read\n Hardware-->>Kernel: Interrupt on completion\n Kernel->>Kernel: Copy to page cache\n Kernel->>Kernel: Copy to user buffer\n end\n \n Kernel->>CPU: Return bytes_read\n Note over CPU: Mode switch to user\n CPU->>App: Return from read()"},"type":"mermaid-excalidraw"}],"titleType":"number","titleNumber":2},{"id":"c-library-abstraction","title":"The C Library: stdio and Beyond","content":[{"data":{"content":"While raw system calls provide complete I/O functionality, most applications don't use them directly. Instead, they use the **C standard library (libc)**, which wraps system calls with higher-level abstractions. The most prominent of these is the **stdio library** (``), which provides buffered, formatted I/O operations.\n\n**Why Use Library Functions Instead of System Calls?**\n\nThe primary motivations are performance, convenience, and portability:"},"type":"text"},{"data":{"items":["**Buffering** — Libraries batch multiple small operations into fewer, larger system calls, dramatically reducing mode-switch overhead","**Formatting** — Functions like `printf()` and `scanf()` handle complex data formatting that would be tedious with raw `read()`/`write()`","**Portability** — The C standard defines these functions precisely, ensuring code works across different operating systems","**Error Handling** — Libraries provide consistent error reporting mechanisms like `ferror()` and `feof()`","**Line-Oriented I/O** — Functions like `fgets()` and `fputs()` handle line boundaries transparently"],"title":{"icon":"Target","text":"Benefits of Library I/O Functions","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**FILE Streams vs File Descriptors:**\n\nThe stdio library introduces the concept of a **FILE stream**—an opaque structure that encapsulates a file descriptor plus additional buffering and state information:"},"type":"text"},{"data":{"left":[{"data":{"items":["Represented by `FILE *` pointer","Includes user-space buffer","Tracks buffer state (position, dirty)","Maintains error and EOF flags","Examples: `fopen()`, `fread()`, `fprintf()`"],"title":{"icon":"Info","text":"FILE Stream (stdio)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Simple integer (0, 1, 2, ...)","No user-space buffering","Kernel tracks position only","Errors via errno global","Examples: `open()`, `read()`, `write()`"],"title":{"icon":"Info","text":"File Descriptor (Unix)","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"stdio_vs_syscall.c","languages":[{"code":"$6c","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Converting Between Streams and Descriptors","content":"You can convert between FILE streams and file descriptors using `fileno()` (get the fd from a FILE *) and `fdopen()` (create a FILE * from an fd). However, mixing buffered and unbuffered operations on the same file can lead to subtle bugs—the stdio buffer and the kernel's view of the file position may become inconsistent. Always use `fflush()` before switching modes.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"buffering-strategies","title":"Buffering Strategies in User Space","content":[{"data":{"content":"Buffering is perhaps the most important optimization in user-level I/O. The stdio library implements **three distinct buffering modes**, each suited to different use cases:\n\n**1. Fully Buffered (Block Buffered)**\n\nData is accumulated in a user-space buffer until it reaches a certain size (typically 4KB-8KB), then flushed to the kernel in a single system call. This is the default for regular files.\n\n**2. Line Buffered**\n\nData is accumulated until a newline character (`\n`) is encountered, then flushed. This is the default for terminal devices connected to `stdout`.\n\n**3. Unbuffered**\n\nEach write operation immediately triggers a system call. This is the default for `stderr` to ensure error messages appear immediately."},"type":"text"},{"data":{"rows":[["Fully Buffered","`_IOFBF`","Buffer full or `fflush()`","Regular files"],["Line Buffered","`_IOLBF`","Newline, buffer full, or input request","Interactive terminals"],["Unbuffered","`_IONBF`","Every operation","Error output, debugging"]],"caption":"stdio Buffering Modes","headers":["Mode","Constant","Flush Trigger","Typical Use Case"]},"type":"table"},{"data":{"fileName":"buffering_modes.c","languages":[{"code":"#include \n\nint main() {\n FILE *fp = fopen(\"/tmp/output.txt\", \"w\");\n if (!fp) return 1;\n \n // Set fully buffered with 16KB buffer\n char *my_buffer = malloc(16384);\n setvbuf(fp, my_buffer, _IOFBF, 16384);\n \n // Alternatively, use setbuf() for simpler cases:\n // setbuf(fp, NULL); // Unbuffered\n // setbuf(fp, my_buffer); // Fully buffered with BUFSIZ bytes\n \n // Or use line buffering for interactive output:\n // setvbuf(fp, NULL, _IOLBF, 0);\n \n // Write operations accumulate in my_buffer\n for (int i = 0; i < 10000; i++) {\n fprintf(fp, \"Data line %d\n\", i);\n }\n \n // Force flush before close\n fflush(fp);\n \n fclose(fp);\n free(my_buffer);\n return 0;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**The Buffer Anatomy:**\n\nA stdio buffer is not just a simple array—it maintains state for efficient operation:"},"type":"text"},{"data":{"height":"280px","mermaidSyntax":"flowchart LR\n subgraph FILEStruct[\"FILE Structure\"]\n direction TB\n FD[\"fd: 3 (file descriptor)\"]\n BUF[\"buffer: 0x7ff...]\"]\n BUFSIZE[\"bufsize: 8192\"]\n POS[\"pos: 2847 (current position)\"]\n FLAGS[\"flags: _IOFBF | _IOWRITE\"]\n ERR[\"error: 0\"]\n EOF[\"eof: 0\"]\n end\n \n subgraph Buffer[\"User-Space Buffer (8KB)\"]\n direction LR\n WRITTEN[\"Written data\n(0 to pos-1)\"]\n EMPTY[\"Available space\n(pos to bufsize-1)\"]\n end\n \n FILEStruct --> Buffer\n \n style FILEStruct fill:#e3f2fd,stroke:#1565c0\n style Buffer fill:#fff3e0,stroke:#ef6c00"},"type":"mermaid-excalidraw"},{"data":{"icon":"Info","title":"When Buffers Are Flushed","content":"Buffers are automatically flushed when: (1) the buffer becomes full, (2) the stream is closed, (3) the program exits normally, (4) `fflush()` is called explicitly, or (5) for line-buffered streams, when a newline is written. For input streams, the buffer may also be flushed when a related output stream needs data—this ensures proper interactive behavior with terminals.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"user-kernel-boundary","title":"Crossing the User-Kernel Boundary","content":[{"data":{"content":"The boundary between user space and kernel space is one of the most critical architectural features of modern operating systems. Every I/O operation must eventually cross this boundary, and understanding the mechanics is essential for writing efficient systems software.\n\n**Why the Boundary Exists:**\n\nThe separation serves multiple essential purposes:"},"type":"text"},{"data":{"items":["**Protection** — Prevents user programs from corrupting kernel data structures or accessing other processes' memory","**Isolation** — A buggy user program cannot crash the entire system","**Resource Control** — The kernel mediates access to hardware, enforcing fair sharing and quotas","**Security** — Privilege escalation requires explicit permission (capabilities, setuid, etc.)","**Abstraction** — Hardware complexity is hidden behind stable system call interfaces"],"title":{"icon":"Target","text":"User-Kernel Separation Benefits","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**The Cost of Crossing:**\n\nCrossing the user-kernel boundary is expensive. A system call typically involves:\n\n1. **Saving User Context** — All CPU registers must be saved\n2. **Mode Switch** — The CPU transitions from ring 3 (user) to ring 0 (kernel) on x86\n3. **TLB and Cache Effects** — Different address space mappings may cause cache misses\n4. **Security Checks** — The kernel validates all parameters\n5. **Potential Preemption** — The kernel may schedule other processes\n6. **Restoring Context** — Registers and state are restored on return\n\nModern CPUs have optimized this (with `syscall`/`sysret` instructions replacing older `int 0x80`), but the overhead remains significant—typically **100-1000 cycles** on modern hardware."},"type":"text"},{"data":{"fileName":"syscall_overhead.c","languages":[{"code":"$6d","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Minimizing Boundary Crossings","content":"High-performance applications minimize user-kernel transitions through: (1) buffering many small operations, (2) using memory-mapped files to avoid explicit read/write calls, (3) using `writev()`/`readv()` for scatter-gather I/O, (4) leveraging async I/O to batch multiple operations, and (5) using vDSO for read-only kernel data access.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"standard-file-descriptors","title":"Standard File Descriptors","content":[{"data":{"content":"Unix established a convention that every process starts with three pre-opened file descriptors, providing immediate I/O connectivity:"},"type":"text"},{"data":{"rows":[["0","Standard Input","`STDIN_FILENO` / `stdin`","Terminal keyboard","Line buffered (terminal)"],["1","Standard Output","`STDOUT_FILENO` / `stdout`","Terminal display","Line buffered (terminal) / Block buffered (file)"],["2","Standard Error","`STDERR_FILENO` / `stderr`","Terminal display","Unbuffered"]],"caption":"Standard Unix File Descriptors","headers":["Descriptor","Name","Constant","Default Connection","Buffering"]},"type":"table"},{"data":{"content":"**Why Three Standard Streams?**\n\nThis design enables powerful composition through shell redirection and pipes:\n\n```bash\n# Redirect stdout to file\n./program > output.txt\n\n# Redirect stdin from file\n./program < input.txt\n\n# Pipe stdout of one program to stdin of another\n./producer | ./consumer\n\n# Redirect stderr separately\n./program 2> errors.log\n\n# Redirect both stdout and stderr\n./program > output.txt 2>&1\n```\n\nThe separation of stdout and stderr is particularly important: normal output goes to stdout (which can be redirected or piped) while error messages go to stderr (which typically remains connected to the terminal)."},"type":"text"},{"data":{"fileName":"standard_streams.c","languages":[{"code":"#include \n#include \n#include \n\nint main() {\n // Using FILE* streams (stdio)\n fprintf(stdout, \"This is standard output (buffered)\n\");\n fprintf(stderr, \"This is standard error (unbuffered)\n\");\n \n // Using raw file descriptors (syscalls)\n const char *msg1 = \"Direct write to stdout\n\";\n const char *msg2 = \"Direct write to stderr\n\";\n \n write(STDOUT_FILENO, msg1, strlen(msg1));\n write(STDERR_FILENO, msg2, strlen(msg2));\n \n // Demonstrate buffering difference\n printf(\"This goes to stdout...\"); // May not appear immediately!\n fprintf(stderr, \"This goes to stderr immediately.\n\");\n \n // Force stdout flush\n fflush(stdout);\n printf(\"Now this appears.\n\");\n \n // Check if connected to a terminal\n if (isatty(STDOUT_FILENO)) {\n printf(\"stdout is connected to a terminal\n\");\n } else {\n printf(\"stdout is redirected to a file or pipe\n\");\n }\n \n return 0;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Buffering Surprises","content":"When stdout is connected to a terminal, it's line-buffered, so `printf(\"hello\n\")` appears immediately. When redirected to a file or pipe, stdout becomes fully buffered, potentially delaying output significantly. This is why logs sometimes appear out of order or delayed in production systems. Use `fflush(stdout)` after critical messages or configure unbuffered output with `setbuf(stdout, NULL)`.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"error-handling","title":"Error Handling in User-Level I/O","content":[{"data":{"content":"Robust error handling is crucial in I/O operations. Unlike computational errors that might be caught by exceptions or assertions, I/O errors can originate from external factors: disk failures, network disconnections, permission denials, or resource exhaustion. User-level I/O provides two complementary error-reporting mechanisms:\n\n**1. System Call Error Reporting (errno):**\n\nWhen a system call fails, it returns -1 and sets the global variable `errno` to indicate the specific error:"},"type":"text"},{"data":{"fileName":"errno_handling.c","languages":[{"code":"$6e","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"**2. stdio Error Reporting:**\n\nThe stdio library provides its own error tracking through the FILE structure:"},"type":"text"},{"data":{"fileName":"stdio_errors.c","languages":[{"code":"#include \n#include \n\nint main() {\n FILE *fp = fopen(\"/etc/shadow\", \"r\"); // Likely permission denied\n \n if (fp == NULL) {\n perror(\"fopen() failed\");\n return 1;\n }\n \n char buffer[1024];\n \n while (fgets(buffer, sizeof(buffer), fp) != NULL) {\n printf(\"%s\", buffer);\n }\n \n // After loop: check WHY we stopped\n if (ferror(fp)) {\n // An error occurred during reading\n perror(\"Read error\");\n clearerr(fp); // Reset error indicator\n } else if (feof(fp)) {\n // Normal end of file\n printf(\"\n[Reached end of file]\n\");\n }\n \n fclose(fp);\n return 0;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"rows":[["2","`ENOENT`","No such file or directory","File doesn't exist"],["13","`EACCES`","Permission denied","Insufficient privileges"],["9","`EBADF`","Bad file descriptor","Invalid or closed fd"],["28","`ENOSPC`","No space left on device","Disk full"],["27","`EFBIG`","File too large","Exceeded file size limit"],["4","`EINTR`","Interrupted system call","Signal received during I/O"],["11","`EAGAIN` / `EWOULDBLOCK`","Resource temporarily unavailable","Non-blocking operation would block"]],"caption":"Common I/O Error Codes","headers":["errno Value","Constant","Description","Typical Cause"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"EINTR: The Interrupt Trap","content":"When a system call is interrupted by a signal, it may return -1 with errno set to EINTR, even though no actual error occurred. Robust I/O code must either restart the operation (`while (ret == -1 && errno == EINTR) { ret = read(...); }`) or use `SA_RESTART` flag when installing signal handlers. This is a notorious source of bugs in systems programming.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: The User-Level I/O Layer","content":[{"data":{"content":"The user-level I/O layer is the programmer's primary interface to the I/O subsystem. It determines how applications request I/O services and profoundly affects performance, portability, and reliability. Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**System calls are the gateway** — All I/O ultimately flows through kernel system calls like `read()`, `write()`, `open()`, and `close()`. These provide the primitive operations upon which everything else is built.","**Library functions add crucial abstractions** — The stdio library provides buffering, formatting, and portable interfaces that dramatically improve both performance and developer productivity.","**Buffering is the primary optimization** — By batching many small operations into fewer large ones, user-space buffering reduces the expensive user-kernel transitions by orders of magnitude.","**File descriptors vs FILE streams** — Understanding when to use raw descriptors versus stdio streams is essential. Use descriptors for low-level control; use streams for convenience and performance.","**Standard streams enable composition** — The stdin/stdout/stderr convention enables powerful Unix-style pipes and redirection, making programs naturally composable.","**Error handling must be thorough** — I/O operations can fail for many reasons beyond programmer control. Always check return values and handle errors appropriately."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nHaving examined the user-level I/O layer, we'll descend one level in the stack to explore **Device-Independent I/O Software**—the kernel layer that provides uniform interfaces across all device types, handling naming, protection, buffering, and device allocation."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand how user-level I/O operates: from high-level library calls through buffering strategies to the system call boundary. This foundation prepares you to appreciate how the kernel layers below transform these abstract requests into concrete hardware operations.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_7ab653e6f50c115a4760b11b54d52afe","title":"Device-Independent Software","order":1,"content":null,"isLocked":true},{"id":"seed_a056a5f1bd22d7792be0d86c01504ced","title":"Device Drivers","order":2,"content":null,"isLocked":true},{"id":"seed_6108fc01daab26d00fc6f24f3ac29444","title":"Interrupt Handlers","order":3,"content":null,"isLocked":true},{"id":"seed_b4778643aec5918933c29eb3dabd4067","title":"Hardware Layer","order":4,"content":null,"isLocked":true}]}}