System Call Types - Learning Module

Loading content...

0/227

Device Management System Calls

Hardware Through the Lens of Software

Modern computers interface with an astonishing diversity of hardware: disk drives, network cards, graphics processors, USB peripherals, sensors, audio devices, and countless specialized controllers. Yet application programmers rarely interact with hardware registers directly—nor should they. The operating system provides an abstraction layer that presents devices through familiar interfaces, enabling software to manipulate hardware without knowing whether it's dealing with a mechanical hard drive, solid-state storage, or a network filesystem.

Device management system calls represent the third major category in our taxonomy. While file management handles persistent storage, device management extends similar concepts to all forms of hardware I/O. The genius of the UNIX model—treating devices as files in /dev/—means that much of what we learned about file operations applies directly to devices. However, devices introduce unique challenges: configuration complexity, performance characteristics, asynchronous behavior, and hardware-specific capabilities that transcend the simple read/write model.

Understanding device management system calls illuminates how operating systems bridge the gap between portable software and platform-specific hardware—a foundational skill for systems programmers, driver developers, and anyone seeking to understand what happens beneath high-level abstractions.

What You Will Learn

By the end of this page, you will understand how operating systems abstract devices through special files, how the ioctl() system call provides device-specific configuration, how device drivers bridge kernel and hardware, and how select()/poll()/epoll() enable efficient I/O multiplexing across multiple devices. You'll grasp both the unified interface philosophy and the pragmatic accommodations for device diversity.

The Device File Abstraction — /dev/ Explained

In UNIX and UNIX-like systems, devices are represented as special files in the /dev/ directory. This uniform representation enables programs to use standard file operations (open, read, write, close) on hardware devices, treating a terminal, disk partition, or random number generator identically at the system call level.

Types of Device Files

Two fundamental categories exist:

Character Devices (c in ls -l output):

Data accessed as a stream of bytes
No buffering imposed by the kernel
Examples: keyboards, mice, terminals, audio devices
Operations have immediate effect on hardware
May not support seeking

Block Devices (b in ls -l output):

Data accessed in fixed-size blocks (typically 512 bytes or larger)
Kernel provides block buffering
Examples: hard drives, SSDs, USB mass storage
Supports random access via lseek()
Usually not accessed directly; filesystems live atop them

Common Device Files and Their Purposes
Device Path	Type	Purpose
/dev/null	Char	Data sink—writes succeed but discard data; reads return EOF
/dev/zero	Char	Infinite source of null bytes
/dev/random	Char	Blocking source of random data from entropy pool
/dev/urandom	Char	Non-blocking pseudo-random data
/dev/tty	Char	Current process's controlling terminal
/dev/pts/N	Char	Pseudo-terminal slave devices
/dev/sda	Block	First SCSI/SATA disk (whole device)
/dev/sda1	Block	First partition on /dev/sda
/dev/nvme0n1	Block	First NVMe SSD
/dev/loop0	Block	Loopback device (file as block device)

device_files.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/stat.h>
 
void demonstrate_device_files() {
    // ========================================
    // Reading random data from /dev/urandom
    // ========================================
    int fd = open("/dev/urandom", O_RDONLY);
    if (fd != -1) {
        unsigned char random_bytes[16];
        read(fd, random_bytes, sizeof(random_bytes));
        
        printf("Random bytes: ");
        for (int i = 0; i < 16; i++) {
            printf("%02x", random_bytes[i]);
        }
        printf("\n");
        close(fd);
    }
    
    // ========================================
    // Discarding data with /dev/null
    // ========================================
    fd = open("/dev/null", O_WRONLY);
    if (fd != -1) {
        // This write "succeeds" but data is discarded
        const char *garbage = "This data goes nowhere";
        ssize_t written = write(fd, garbage, 22);
        printf("Wrote %zd bytes to /dev/null\n", written);
        close(fd);
    }
    
    // ========================================
    // Getting zeros from /dev/zero
    // ========================================
    fd = open("/dev/zero", O_RDONLY);
    if (fd != -1) {
        char buffer[8];
        read(fd, buffer, sizeof(buffer));
        
        printf("Bytes from /dev/zero: ");
        for (int i = 0; i < 8; i++) {
            printf("%02x ", (unsigned char)buffer[i]);
        }
        printf("(all zeros)\n");
        close(fd);
    }
    
    // ========================================
    // Examining device file metadata
    // ========================================
    struct stat st;
    if (stat("/dev/null", &st) == 0) {
        // Major and minor device numbers identify the driver and device
        printf("/dev/null device numbers: major=%d, minor=%d\n",
               major(st.st_rdev), minor(st.st_rdev));
    }
}
 
int main() {
    demonstrate_device_files();
    return 0;
}

Major and Minor Device Numbers

Each device file has two numbers that identify it:

Major number: Identifies the driver responsible for the device class
Minor number: Identifies the specific device instance within the class

For example, all SCSI disks might have major number 8, with minor numbers distinguishing /dev/sda (minor 0), /dev/sdb (minor 16), and their partitions. These numbers are visible via ls -l /dev/ or stat().

The kernel uses these numbers to route I/O operations to the appropriate device driver—the major number selects the driver, the minor number is passed to the driver to select the specific device.

udev and Dynamic Device Management

Modern Linux systems use udev to dynamically create device files when hardware is detected and remove them when hardware is disconnected. This replaced the static /dev/ of older systems. udev rules (in /etc/udev/rules.d/) can customize device names, permissions, and trigger actions when devices appear. Understanding udev is essential for managing hotpluggable devices and embedded systems.

ioctl() — The Swiss Army Knife of Device Control

While read() and write() handle data transfer, many devices require configuration and control operations that don't fit the data stream model. How do you set a terminal's baud rate? Query a disk's geometry? Configure a network interface's IP address? The answer is ioctl() (input/output control).

int ioctl(int fd, unsigned long request, ... /* arg */);

How ioctl() Works

The request parameter is a magic number that specifies the operation. The optional third argument is typically a pointer to a structure containing operation-specific data. Each device class defines its own set of ioctl commands.

This design has trade-offs:

Flexibility: Can express any device-specific operation
No type safety: Request codes and arguments are weakly typed
Documentation dependence: Must consult driver or header files for semantics
Portability challenges: Request codes vary between operating systems

ioctl_examples.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <linux/fs.h>      // BLKGETSIZE64
#include <termios.h>       // Terminal ioctls
 
void demonstrate_terminal_ioctl() {
    // ========================================
    // Terminal size query
    // ========================================
    struct winsize ws;
    
    if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &ws) == 0) {
        printf("Terminal size: %d rows x %d columns\n", 
               ws.ws_row, ws.ws_col);
        printf("Pixel size: %d x %d\n", ws.ws_xpixel, ws.ws_ypixel);
    }
    
    // ========================================
    // Terminal settings via termios
    // (Higher-level than raw ioctl)
    // ========================================
    struct termios term;
    if (tcgetattr(STDIN_FILENO, &term) == 0) {
        printf("Terminal flags:\n");
        printf("  ECHO: %s\n", (term.c_lflag & ECHO) ? "on" : "off");
        printf("  ICANON (line mode): %s\n", 
               (term.c_lflag & ICANON) ? "on" : "off");
    }
}
 
void demonstrate_block_device_ioctl() {
    // ========================================
    // Query block device size
    // ========================================
    // Note: Usually need read permission on the device
    int fd = open("/dev/sda", O_RDONLY);
    if (fd != -1) {
        unsigned long long size_bytes;
        
        if (ioctl(fd, BLKGETSIZE64, &size_bytes) == 0) {
            printf("/dev/sda size: %llu bytes (%.2f GB)\n",
                   size_bytes, (double)size_bytes / (1024*1024*1024));
        }
        
        // Query sector size
        int sector_size;
        if (ioctl(fd, BLKSSZGET, &sector_size) == 0) {
            printf("Sector size: %d bytes\n", sector_size);
        }
        
        // Query read-only status
        int read_only;
        if (ioctl(fd, BLKROGET, &read_only) == 0) {
            printf("Read-only: %s\n", read_only ? "yes" : "no");
        }
        
        close(fd);
    } else {
        perror("open /dev/sda (need root)");
    }
}
 
void demonstrate_network_ioctl() {
    // ========================================
    // Network interface queries
    // ========================================
    #include <net/if.h>
    #include <sys/socket.h>
    #include <netinet/in.h>
    #include <arpa/inet.h>
    
    int sock = socket(AF_INET, SOCK_DGRAM, 0);
    if (sock == -1) return;
    
    struct ifreq ifr;
    strncpy(ifr.ifr_name, "eth0", IFNAMSIZ);
    
    // Get interface flags
    if (ioctl(sock, SIOCGIFFLAGS, &ifr) == 0) {
        printf("eth0 flags: 0x%x\n", ifr.ifr_flags);
        printf("  UP: %s\n", (ifr.ifr_flags & IFF_UP) ? "yes" : "no");
        printf("  RUNNING: %s\n", (ifr.ifr_flags & IFF_RUNNING) ? "yes" : "no");
    }
    
    // Get IP address
    if (ioctl(sock, SIOCGIFADDR, &ifr) == 0) {
        struct sockaddr_in *addr = (struct sockaddr_in *)&ifr.ifr_addr;
        printf("eth0 IP: %s\n", inet_ntoa(addr->sin_addr));
    }
    
    // Get MAC address
    if (ioctl(sock, SIOCGIFHWADDR, &ifr) == 0) {
        unsigned char *mac = (unsigned char *)ifr.ifr_hwaddr.sa_data;
        printf("eth0 MAC: %02x:%02x:%02x:%02x:%02x:%02x\n",
               mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
    }
    
    close(sock);
}

Common ioctl Request Categories
Device Type	Example Requests	Purpose
Terminal	TIOCGWINSZ, TIOCGPTN	Window size, PTY number
Block device	BLKGETSIZE64, BLKFLSBUF	Size, flush buffers
Network	SIOCGIFADDR, SIOCSIFFLAGS	Get/set address, bring interface up/down
Sound	SNDCTL_DSP_SPEED	Set sample rate
Watchdog	WDIOC_SETTIMEOUT	Set watchdog timeout
Loop device	LOOP_SET_FD	Associate file with loop device

ioctl Security Considerations

ioctl() requests bypass normal access control and directly invoke driver code. A bug in ioctl handler argument validation can lead to kernel memory corruption or privilege escalation. Many security vulnerabilities stem from ioctl handlers. Kernel developers carefully validate all ioctl arguments, and security-focused systems minimize new ioctl interfaces in favor of sysfs, netlink, or /proc.

Device Request and Release Mechanisms

Certain devices are inherently exclusive—only one process should use them at a time. Consider a tape drive: two processes writing simultaneously would produce garbage. Or a hardware security module: concurrent access might leak keys. Device management must support exclusive access and resource arbitration.

Exclusive Opens

Some devices enforce exclusivity at the driver level:

// Open fails if device already open
int fd = open("/dev/printer", O_WRONLY | O_EXCL);

The O_EXCL flag, combined with device driver support, ensures only one process accesses the device. Subsequent opens return EBUSY.

File Locking for Devices

More commonly, cooperating processes use advisory or mandatory locking:

device_locking.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/file.h>
#include <errno.h>
 
int acquire_device_exclusive(const char *device_path) {
    int fd = open(device_path, O_RDWR);
    if (fd == -1) return -1;
    
    // ========================================
    // Method 1: flock() - Advisory file locks
    // ========================================
    // LOCK_EX: Exclusive lock
    // LOCK_NB: Non-blocking (return immediately if can't lock)
    if (flock(fd, LOCK_EX | LOCK_NB) == -1) {
        if (errno == EWOULDBLOCK) {
            fprintf(stderr, "Device is in use by another process\n");
        }
        close(fd);
        return -1;
    }
    
    printf("Acquired exclusive access to %s\n", device_path);
    return fd;
}
 
void release_device(int fd) {
    // flock() locks are automatically released on close
    // But explicit unlock is clearer
    flock(fd, LOCK_UN);
    close(fd);
    printf("Released device\n");
}
 
// Alternative: fcntl record locking (works over NFS)
int acquire_with_fcntl(const char *device_path) {
    int fd = open(device_path, O_RDWR);
    if (fd == -1) return -1;
    
    struct flock fl = {
        .l_type = F_WRLCK,      // Write (exclusive) lock
        .l_whence = SEEK_SET,   // Lock from beginning
        .l_start = 0,           // Offset 0
        .l_len = 0,             // 0 = entire file
    };
    
    // F_SETLK: Non-blocking, returns immediately
    // F_SETLKW: Blocking, waits for lock
    if (fcntl(fd, F_SETLK, &fl) == -1) {
        if (errno == EACCES || errno == EAGAIN) {
            // Find out who holds the lock
            fl.l_type = F_WRLCK;
            fcntl(fd, F_GETLK, &fl);
            fprintf(stderr, "Locked by PID %d\n", fl.l_pid);
        }
        close(fd);
        return -1;
    }
    
    return fd;
}
 
// Pattern: Lock file for device (standard convention)
int acquire_via_lockfile(const char *device_path) {
    char lockfile[256];
    snprintf(lockfile, sizeof(lockfile), "/var/lock/LCK..%s", 
             strrchr(device_path, '/') + 1);
    
    int lock_fd = open(lockfile, O_CREAT | O_EXCL | O_WRONLY, 0644);
    if (lock_fd == -1) {
        if (errno == EEXIST) {
            // Read PID from existing lockfile
            int existing = open(lockfile, O_RDONLY);
            char pid_str[20];
            read(existing, pid_str, sizeof(pid_str));
            close(existing);
            printf("Device locked by PID %s", pid_str);
            return -1;
        }
        return -1;
    }
    
    // Write our PID to lockfile
    char pid_str[20];
    snprintf(pid_str, sizeof(pid_str), "%d\n", getpid());
    write(lock_fd, pid_str, strlen(pid_str));
    close(lock_fd);
    
    // Now open the actual device
    int fd = open(device_path, O_RDWR);
    if (fd == -1) {
        unlink(lockfile);  // Clean up lockfile on failure
        return -1;
    }
    
    return fd;
}

Reference Counting in the Kernel

Internally, the kernel maintains reference counts for device access:

open() increments the device's open count; driver's open method is called
dup()/fork() increments the file description reference count
close() decrements the count; when it reaches zero, driver's release method is called
Drivers can refuse opens (return -EBUSY) or allow multiple (implement sharing)

Device Allocation APIs

Some device classes have formal allocation mechanisms beyond open/close:

DRM (Direct Rendering Manager): GPU allocation via ioctl
V4L2 (Video4Linux2): Video buffer allocation
RDMA: Remote memory registration
VFIO: Device passthrough for virtualization

These APIs involve allocating hardware resources (buffers, address mappings) that exist beyond the file descriptor lifetime and require explicit deallocation.

Lock Files Convention

The traditional /var/lock/LCK..devicename convention dates from serial port management. Programs like pppd, minicom, and modem dialers use this to prevent conflicts. The lockfile contains the PID of the holding process, enabling stale lock detection. While this is advisory (any process can open the device), well-behaved programs respect lockfiles.

Device Drivers — The Kernel-Hardware Bridge

Every system call on a device file is translated into a call to the corresponding device driver. Understanding this translation reveals how the operating system achieves hardware abstraction.

The Driver Operation Table

In Linux, character device drivers register a structure of function pointers:

struct file_operations {
    struct module *owner;
    loff_t (*llseek)(struct file *, loff_t, int);
    ssize_t (*read)(struct file *, char __user *, size_t, loff_t *);
    ssize_t (*write)(struct file *, const char __user *, size_t, loff_t *);
    long (*unlocked_ioctl)(struct file *, unsigned int, unsigned long);
    int (*mmap)(struct file *, struct vm_area_struct *);
    int (*open)(struct inode *, struct file *);
    int (*release)(struct inode *, struct file *);
    int (*fsync)(struct file *, loff_t, loff_t, int datasync);
    /* ... more operations ... */
};

When a user calls read(fd, buf, count) on a device, the kernel:

Looks up the file description from fd
Identifies the device's major number
Finds the registered driver for that major
Calls the driver's read function with the request

System Call to Driver Function Mapping
System Call	Driver Function	Driver Responsibility
open()	open()	Allocate resources, initialize state, increment counters
close()	release()	Free resources, decrement counters
read()	read()	Transfer data from device to user buffer
write()	write()	Transfer data from user buffer to device
lseek()	llseek()	Update or reject position change
ioctl()	unlocked_ioctl()	Handle device-specific commands
mmap()	mmap()	Map device memory into process address space
poll()/select()	poll()	Report readiness for I/O

driver_skeleton.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
/* Conceptual skeleton of a character device driver */
#include <linux/module.h>
#include <linux/fs.h>
#include <linux/cdev.h>
#include <linux/uaccess.h>
 
#define DEVICE_NAME "mydevice"
#define BUFFER_SIZE 1024
 
static int major;
static char device_buffer[BUFFER_SIZE];
static int buffer_len = 0;
 
static int mydevice_open(struct inode *inode, struct file *file) {
    printk(KERN_INFO "mydevice: opened by process %d\n", current->pid);
    // Allocate per-open resources if needed
    // file->private_data = kmalloc(...);
    return 0;  // Success
}
 
static int mydevice_release(struct inode *inode, struct file *file) {
    printk(KERN_INFO "mydevice: closed\n");
    // Free per-open resources
    // kfree(file->private_data);
    return 0;
}
 
static ssize_t mydevice_read(struct file *file, char __user *buf, 
                             size_t count, loff_t *offset) {
    int bytes_to_read = min((int)count, buffer_len - (int)*offset);
    
    if (bytes_to_read <= 0) return 0;  // EOF
    
    // CRITICAL: copy_to_user validates user buffer
    // Never use memcpy to user pointers!
    if (copy_to_user(buf, device_buffer + *offset, bytes_to_read)) {
        return -EFAULT;  // Bad user address
    }
    
    *offset += bytes_to_read;
    return bytes_to_read;
}
 
static ssize_t mydevice_write(struct file *file, const char __user *buf,
                              size_t count, loff_t *offset) {
    int bytes_to_write = min((int)count, BUFFER_SIZE - (int)*offset);
    
    if (bytes_to_write <= 0) return -ENOMEM;
    
    // CRITICAL: copy_from_user validates user buffer
    if (copy_from_user(device_buffer + *offset, buf, bytes_to_write)) {
        return -EFAULT;
    }
    
    *offset += bytes_to_write;
    buffer_len = max(buffer_len, (int)*offset);
    return bytes_to_write;
}
 
static long mydevice_ioctl(struct file *file, unsigned int cmd, 
                           unsigned long arg) {
    switch (cmd) {
        case 0x1001:  // Clear buffer
            buffer_len = 0;
            return 0;
        case 0x1002:  // Get buffer length
            return buffer_len;
        default:
            return -ENOTTY;  // Inappropriate ioctl for device
    }
}
 
static struct file_operations mydevice_fops = {
    .owner    = THIS_MODULE,
    .open     = mydevice_open,
    .release  = mydevice_release,
    .read     = mydevice_read,
    .write    = mydevice_write,
    .unlocked_ioctl = mydevice_ioctl,
};
 
static int __init mydevice_init(void) {
    major = register_chrdev(0, DEVICE_NAME, &mydevice_fops);
    if (major < 0) return major;
    printk(KERN_INFO "mydevice registered with major %d\n", major);
    // Note: still need to create /dev/mydevice with mknod or udev
    return 0;
}
 
static void __exit mydevice_exit(void) {
    unregister_chrdev(major, DEVICE_NAME);
    printk(KERN_INFO "mydevice unregistered\n");
}
 
module_init(mydevice_init);
module_exit(mydevice_exit);
MODULE_LICENSE("GPL");

User Space Safety

Driver code runs in kernel space with full privileges. The copy_to_user() and copy_from_user() functions are MANDATORY for data transfer—they validate that user-provided pointers actually point to user-accessible memory. Skipping these checks creates security vulnerabilities where attackers can read/write arbitrary kernel memory. This is a primary source of kernel exploits.

I/O Multiplexing — Monitoring Multiple Devices

Real-world programs often need to respond to events from multiple sources simultaneously: network sockets, terminals, pipes, and device files. Rather than dedicating a thread to each source, I/O multiplexing allows a single thread to wait for activity on many descriptors efficiently.

select() — The Classic Approach

int select(int nfds, fd_set *readfds, fd_set *writefds,
           fd_set *exceptfds, struct timeval *timeout);

select() monitors up to nfds file descriptors, blocking until at least one is ready for reading, writing, or has an exception condition. Limitations:

Maximum ~1024 descriptors (FD_SETSIZE)
Must rebuild fd_sets after each call
O(n) kernel scanning of descriptor set

poll() — Improved Flexibility

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

poll() uses an array of structures, removing the FD_SETSIZE limitation and avoiding the rebuild requirement. Still O(n) scanning.

multiplexing_examples.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/select.h>
#include <poll.h>
#include <sys/epoll.h>
#include <errno.h>
 
// ========================================
// select() Example: Wait for stdin or timeout
// ========================================
void select_example() {
    fd_set readfds;
    struct timeval timeout;
    
    printf("select: Type something within 5 seconds...\n");
    
    FD_ZERO(&readfds);
    FD_SET(STDIN_FILENO, &readfds);  // Watch stdin
    
    timeout.tv_sec = 5;
    timeout.tv_usec = 0;
    
    int result = select(STDIN_FILENO + 1, &readfds, NULL, NULL, &timeout);
    
    if (result == -1) {
        perror("select");
    } else if (result == 0) {
        printf("select: Timeout - no input\n");
    } else {
        if (FD_ISSET(STDIN_FILENO, &readfds)) {
            char buf[100];
            ssize_t n = read(STDIN_FILENO, buf, sizeof(buf) - 1);
            buf[n] = '\0';
            printf("select: Read: %s", buf);
        }
    }
}
 
// ========================================
// poll() Example: Monitor multiple sources
// ========================================
void poll_example(int fd1, int fd2) {
    struct pollfd pfds[3];
    
    pfds[0].fd = STDIN_FILENO;
    pfds[0].events = POLLIN;
    
    pfds[1].fd = fd1;
    pfds[1].events = POLLIN;
    
    pfds[2].fd = fd2;
    pfds[2].events = POLLIN | POLLPRI;  // Normal + priority data
    
    printf("poll: Waiting for activity...\n");
    
    int result = poll(pfds, 3, 5000);  // 5 second timeout
    
    if (result == -1) {
        perror("poll");
        return;
    } else if (result == 0) {
        printf("poll: Timeout\n");
        return;
    }
    
    // Check which descriptors are ready
    for (int i = 0; i < 3; i++) {
        if (pfds[i].revents & POLLIN) {
            printf("poll: fd %d is readable\n", pfds[i].fd);
        }
        if (pfds[i].revents & POLLHUP) {
            printf("poll: fd %d hung up\n", pfds[i].fd);
        }
        if (pfds[i].revents & POLLERR) {
            printf("poll: fd %d has error\n", pfds[i].fd);
        }
    }
}
 
// ========================================
// epoll Example: Scalable event handling
// ========================================
void epoll_example(int *fds, int nfds) {
    // Create epoll instance
    int epfd = epoll_create1(0);
    if (epfd == -1) {
        perror("epoll_create1");
        return;
    }
    
    // Add all descriptors to watch
    for (int i = 0; i < nfds; i++) {
        struct epoll_event ev;
        ev.events = EPOLLIN;
        ev.data.fd = fds[i];
        
        if (epoll_ctl(epfd, EPOLL_CTL_ADD, fds[i], &ev) == -1) {
            perror("epoll_ctl");
            close(epfd);
            return;
        }
    }
    
    // Event loop
    struct epoll_event events[10];
    
    while (1) {
        int nready = epoll_wait(epfd, events, 10, 5000);
        
        if (nready == -1) {
            if (errno == EINTR) continue;  // Interrupted by signal
            perror("epoll_wait");
            break;
        } else if (nready == 0) {
            printf("epoll: Timeout\n");
            break;
        }
        
        // Only iterate over READY descriptors (not all!)
        for (int i = 0; i < nready; i++) {
            printf("epoll: fd %d is ready\n", events[i].data.fd);
            // Handle the ready descriptor...
        }
    }
    
    close(epfd);
}

epoll — Linux High-Performance Solution

epoll addresses the O(n) scanning problem:

epoll_create(): Create an epoll instance (kernel data structure)
epoll_ctl(): Add/remove/modify watched descriptors
epoll_wait(): Block until events occur; returns only ready descriptors

Advantages:

O(1) for each wait operation
Watched set persists between calls
Edge-triggered mode for high-throughput scenarios
Scales to millions of connections

Event-Driven Architecture

I/O multiplexing enables event-driven or reactor patterns where a single thread handles thousands of concurrent connections—the foundation of high-performance servers like nginx, Node.js, and Redis.

I/O Multiplexing Mechanism Comparison
Mechanism	Complexity per Wait	Scalability	Portability
select()	O(nfds)	~1024 fd limit	POSIX standard
poll()	O(n watched)	No fd limit	POSIX standard
epoll (Linux)	O(n ready)	Millions of fds	Linux only
kqueue (BSD)	O(n ready)	Millions of fds	BSD/macOS
IOCP (Windows)	O(n ready)	Millions of handles	Windows only

Choosing the Right Mechanism

For portable code handling few descriptors, poll() is often sufficient. For Linux servers with thousands of connections, epoll is essential. For cross-platform high-performance code, use libraries like libuv (Node.js), libevent, or libev that provide a unified API over platform-specific mechanisms.

Advanced Device I/O — DMA, mmap, and Async I/O

High-performance device access often bypasses the read()/write() model entirely to eliminate data copying and achieve maximum throughput.

Memory-Mapped Device I/O

The mmap() system call can map device memory directly into a process's address space:

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);

For devices, this allows:

Direct access to device registers without system calls
Zero-copy access to device DMA buffers
GPU memory access from user space
Frame buffer access for graphics

mmap_device.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <stdint.h>
 
// Example: Memory-mapped access to framebuffer
void framebuffer_example() {
    int fd = open("/dev/fb0", O_RDWR);
    if (fd == -1) {
        perror("open framebuffer");
        return;
    }
    
    // Query framebuffer info via ioctl (FBIOGET_VSCREENINFO, FBIOGET_FSCREENINFO)
    // For simplicity, assume 1920x1080, 32bpp
    size_t fb_size = 1920 * 1080 * 4;  // width * height * bytes per pixel
    
    // Map framebuffer into our address space
    void *fb = mmap(NULL, fb_size, 
                    PROT_READ | PROT_WRITE,  // Read and write
                    MAP_SHARED,               // Changes visible to device
                    fd, 0);
    
    if (fb == MAP_FAILED) {
        perror("mmap framebuffer");
        close(fd);
        return;
    }
    
    // Now we can draw directly!
    uint32_t *pixels = (uint32_t *)fb;
    
    // Fill screen with blue
    for (int i = 0; i < 1920 * 1080; i++) {
        pixels[i] = 0x0000FF00;  // ARGB: green in this format
    }
    
    // Draw a red rectangle
    for (int y = 100; y < 200; y++) {
        for (int x = 100; x < 300; x++) {
            pixels[y * 1920 + x] = 0x00FF0000;  // Red
        }
    }
    
    // Unmap when done
    munmap(fb, fb_size);
    close(fd);
}
 
// Example: DMA buffer for video capture
void video_capture_mmap() {
    // V4L2 uses mmap() for zero-copy video capture
    // 1. Open video device
    // 2. Request buffers (VIDIOC_REQBUFS)
    // 3. Query buffer info (VIDIOC_QUERYBUF)
    // 4. mmap() each buffer
    // 5. Queue buffers (VIDIOC_QBUF)
    // 6. Start streaming (VIDIOC_STREAMON)
    // 7. Poll for frames, dequeue (VIDIOC_DQBUF), process, requeue
    
    // This eliminates copying from kernel to user space!
}

Asynchronous I/O

For maximum parallelism, I/O operations can be submitted and completed asynchronously:

POSIX AIO (aio_read, aio_write):

Submit I/O request and continue
Check status via aio_error() or wait via aio_suspend()
Signal delivery on completion (optional)
Limited by thread pool underlying implementation

Linux io_uring (modern, high-performance):

Shared memory rings between user and kernel
Batch submission and completion
Zero-copy operations
Minimal system call overhead
Used by modern databases and storage systems

When to Use Advanced Device I/O

•mmap() for devices — When direct memory access is needed (GPUs, framebuffers, DMA buffers) and when eliminating copy overhead is critical
•POSIX AIO — When you need portable asynchronous I/O across UNIX systems, though performance varies widely
•io_uring — For maximum Linux I/O performance; databases, storage engines, high-frequency trading
•O_DIRECT — Bypass page cache for applications managing their own caching (databases)

Zero-Copy Significance

Each memory copy consumes CPU cycles and memory bandwidth. High-throughput applications (video streaming, network routers, storage systems) obsess over copy elimination. mmap() and DMA allow data to flow from device to application (or vice versa) without intermediate copies—a factor of 2-3x throughput improvement for I/O-bound workloads.

Summary: Device Management System Calls

Device management system calls bridge the gap between portable software and platform-specific hardware. We've explored how the operating system presents a unified interface while accommodating device diversity:

Key Takeaways

•Device files in /dev/ represent hardware through the unified file abstraction. Character devices handle byte streams; block devices handle fixed-size blocks with buffering.
•ioctl() provides escape hatch for device-specific operations that don't fit read/write semantics—configuration, queries, and control operations.
•Device locking through O_EXCL, flock(), fcntl(), or lock files enables exclusive access for devices that can't be shared.
•Device drivers implement a standard interface (file_operations) that translates system calls into hardware interactions, using copy_to/from_user for safe data transfer.
•I/O multiplexing via select(), poll(), and epoll() enables efficient monitoring of multiple devices, forming the basis of event-driven architectures.
•Advanced I/O techniques—mmap(), async I/O, io_uring—eliminate copying and system call overhead for high-performance device access.

Looking Ahead

Device management completes our exploration of I/O-oriented system calls. Next, we turn to information maintenance system calls—how processes query and modify system state, from time and date to process attributes and system configuration.

Page Complete

You now understand how operating systems abstract diverse hardware through device files, ioctl() for device-specific control, and I/O multiplexing for responsive multi-device handling. This knowledge is essential for systems programming, driver development, and understanding what happens beneath high-level I/O libraries. Next, we'll explore information maintenance system calls for querying and modifying system state.