# /sys

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/sys

## Quick definition

/sys is a special folder in Linux that gives you a live view of your computer's hardware and kernel settings. It lets you see and change how devices are configured without restarting. Think of it as a control panel where every piece of hardware has its own settings file.

## Simple meaning

Imagine you have a giant dashboard that shows every part of your computer's body, the CPU, memory, hard drives, USB ports, and all the tiny internal wires. Every part has its own little card that tells you its name, its speed, and whether it's awake or sleeping. That dashboard is the /sys folder. But this dashboard isn't just for looking, you can actually reach in and adjust some dials. For example, if your laptop lid closes and you want to change whether the computer sleeps or does nothing, you can find that setting in /sys and flip it. The files inside /sys are not real files saved on the hard drive; they are like windows into the operating system's brain. When you open one, the system immediately tells you the current state of that piece of hardware. When you change a file, you're sending a command directly to the kernel. This is very different from normal folders where you store documents. The whole structure is automatically created by the Linux kernel when your computer starts, based on whatever hardware you actually have plugged in. So if you plug in a new USB webcam, a new folder will appear under /sys describing that webcam. This makes /sys incredibly useful for system administrators who need to check what devices are recognized, troubleshoot why a network card isn't working, or adjust power settings without rebooting.

Eveything in /sys follows a strict hierarchy. At the top level you'll find categories like 'block' for storage devices, 'bus' for connections like USB or PCI, 'class' for types of devices like network interfaces or sound cards, and 'devices' which is the master tree of all physical and virtual devices. Inside a device folder you might see files named 'vendor', 'device', 'power', 'driver', and 'uevent'. The 'vendor' file might contain the string '0x8086' which stands for Intel. The 'power' folder might have a file called 'control' where you can write 'on' or 'auto' to manage power saving. Because /sys is a virtual filesystem, any changes you make are lost when you reboot unless you put them in a startup script. Professionals use /sys in shell scripts to automatically configure hardware settings when a server boots. They also read /sys to gather information for monitoring tools like Nagios or Grafana, because you can 'cat' a file in /sys to get the current temperature of your CPU or the speed of a fan.

For everyday learners, the most important thing to remember is that /sys is not somewhere you store your homework, it's a live interface to the kernel. It is meant to be read and sometimes written to, but never used as a permanent storage location. It is also a security boundary: only root (administrator) users can write to most files in /sys, because changing hardware settings can crash the system or cause data loss. Understanding /sys helps you pass general IT certification exams where Linux device management is tested, and it gives you real power to control Linux systems in a job setting.

## Technical definition

/sys is the mount point for the sysfs virtual filesystem in the Linux kernel, introduced in kernel version 2.6 as a replacement for the older and more chaotic /proc filesystem for hardware information. sysfs exports kernel objects (kobjects), internal representations of devices, drivers, buses, and classes, into a hierarchical directory tree that user-space programs can navigate and manipulate using standard file I/O system calls like open(), read(), write(), and close(). sysfs was designed by Patrick Mochel and merged into the mainline Linux kernel in 2003. Its primary purpose is to provide a unified view of the device model, the kernel's internal representation of all hardware and software devices, to user space.

The core data structure in sysfs is the kobject, which represents any kernel object that is reference-counted and part of a parent-child hierarchy. Each kobject is associated with a sysfs directory, and attributes of that kobject are represented as files within that directory. The directory layout follows a well-defined taxonomy: /sys/devices/ contains a device tree mirroring the physical topology of the system, /sys/bus/ groups devices by the bus they are connected to (PCI, USB, I2C, SPI, etc.), /sys/class/ groups devices by their function (net, sound, input, block, etc.), and /sys/block/ is a legacy symlink-based grouping for block devices. /sys/firmware/ exposes firmware-related data, /sys/power/ provides hooks for system power management (suspend, hibernate, sleep states), and /sys/kernel/ contains kernel-specific tuning parameters like NUMA node information or uevent helper settings.

Attributes in sysfs are usually one value per file, following the 'one value per file' design principle that makes parsing simple and deterministic. For example, reading /sys/class/net/eth0/address returns the MAC address of the first Ethernet interface, while /sys/block/sda/size returns the size of the first SCSI disk in 512-byte sectors. Writing to an attribute file triggers the store() method of the underlying kobject, which can change kernel behavior dynamically, for instance, writing '0' to /sys/class/leds/input3::numlock/brightness turns off the Num Lock LED. However, not all attribute files are writable; permissions are enforced via the kernel's permission model, typically requiring root privileges for write access. The sysfs filesystem does not use disk storage; it is entirely memory-based (ramfs-backed) and regenerated on every boot.

In real IT implementations, sysfs is heavily used by hardware detection tools like udev, which uses uevents (kernel events emitted via netlink) to dynamically create device nodes in /dev/. Systemd also reads /sys to enumerate devices and set up dependencies. Diagnostic tools like lspci, lsusb, lshw, and dmidecode ultimately read data from sysfs. Power management daemons (e.g., TLP, Powertop) write to /sys/power/ and /sys/devices/.../power/control to optimize energy consumption. Virtualization platforms like KVM also expose virtual device attributes through sysfs to the host for monitoring. sysfs is also critical for container runtimes; tools like 'cgroups v2' are accessed via /sys/fs/cgroup/, which is a related filesystem but often conflated with sysfs. Certification exams covering Linux system administration, such as CompTIA Linux+, LPIC-1, and Red Hat Certified System Administrator (RHCSA), expect candidates to know the purpose of /sys, the distinction between /sys and /proc, and the ability to locate device attributes for troubleshooting.

## Real-life example

Think of a large office building with hundreds of rooms spread across multiple floors. The /sys directory is like the building's master control board, located in the security office. On this board, there's a small card for every single room, the conference rooms, the server rooms, the break rooms, even the janitor's closet. Each card has a few simple pieces of information: the room number, the floor, the type of equipment (projector, computer, coffee machine), and a status light that shows if the room is occupied, empty, or under maintenance. If the manager wants to know whether the projector in room 3B is powered on, they just walk to the control board, find the card for room 3B, and look at the status light. That status light is like reading a file in /sys, it gives you immediate, live information.

Now imagine that the manager can also flip a switch on the card to force the projector to turn off or on, regardless of what the person in the room is doing. That switch is like writing to a file in /sys, you're sending a command to the room's equipment. However, not every card has a switch; some are strictly read-only because changing them could cause problems. For example, the card for the main electrical panel might show total power usage, but you cannot change it because that reading comes from actual sensors. Similarly, in /sys, a file like 'vendor' is read-only, you cannot change the manufacturer of your network card by writing to it. But a file like 'power/control' might be writable so you can put a device into a low-power state when it's not in use.

If a new room is added to the building, say they build a new server room on the fifth floor, a new card automatically appears on the control board. Likewise, when you plug in a USB flash drive, a new directory appears under /sys/block/ and /sys/bus/usb/devices/ describing that drive. If a room's equipment malfunctions, for example, the projector in room 3B stops responding, the card might show a 'failed' status or disappear entirely. This helps the building manager quickly identify which room needs attention without having to physically inspect every door. In the IT world, a system administrator would do exactly that: run 'cat /sys/block/sda/queue/rotational' to see if a disk is an SSD (0) or HDD (1), or 'cat /sys/class/thermal/thermal_zone0/temp' to check CPU temperature. The analogy with the building control board helps you remember that /sys is a live, centralized, automatically populated dashboard for all hardware components.

## Why it matters

Understanding /sys matters because it gives Linux system administrators a direct, low-level interface to the kernel's hardware model, enabling deep troubleshooting and fine-grained performance tuning without writing custom kernel modules or recompiling the kernel. When a server exhibits erratic behavior, a network interface dropping packets, a disk not being recognized, or a USB device failing to enumerate, the first place to look is often /sys. By reading files like /sys/class/net/eth0/statistics/tx_errors or /sys/block/sda/device/state, you can rapidly pinpoint whether the issue is hardware-related, driver-related, or configuration-related. This ability to retrieve live diagnostic data from the kernel is invaluable for reducing mean time to resolution (MTTR) in production environments.

/sys enables dynamic hardware configuration that would otherwise require a reboot or manual driver reload. For example, you can change the I/O scheduler for a specific block device by writing to /sys/block/sda/queue/scheduler, switching from 'cfq' to 'deadline' or 'noop' to optimize for SSD or rotational media. You can adjust CPU governor scaling using /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor. These knobs are critical in environments where workload patterns change, such as shifting from a database workload to a web server workload, because they allow real-time performance adaptation. Virtualization hosts also rely on /sys to manage PCI passthrough devices, NUMA node binding, and IOMMU groups, all of which are controlled through sysfs attributes.

Security and compliance also tie into /sys. Because it exposes hardware-level information, a malicious user who gains access to /sys can enumerate all devices and potentially infer system vulnerabilities. Linux security frameworks like SELinux and AppArmor restrict access to certain /sys paths to prevent unauthorized configuration changes. For example, restricting write access to /sys/power/state prevents non-root users from putting the system to sleep. In containerized environments, /sys is typically masked or filtered by container runtimes to prevent a container from affecting host hardware. Knowing these security boundaries helps certification candidates understand layered security requirements.

Finally, /sys is a core component of Linux's device driver model. When writing custom device drivers or kernel modules, developers expose tuning parameters and status information through sysfs files. Even if you never write a driver, being able to read those files helps you verify that your hardware is recognized and functioning as expected. /sys is not just a 'nice to know' topic, it is a practical tool that every Linux administrator uses daily for monitoring, configuration, and troubleshooting.

## Why it matters in exams

/sys appears regularly in Linux certification exams for CompTIA Linux+ (XK0-005), LPIC-1 (101 and 102), and Red Hat RHCSA (EX200). CompTIA Linux+ objectives include 'Given a scenario, manage Linux device and file systems' and specifically mention 'sysfs and procfs'. For LPIC-1, exam 102 topic 102.4 deals with 'Manage and configure devices and filesystems' and candidates must be able to locate device information in /sys. The RHCSA exam objectives include 'Manage local storage' which expects candidates to identify disk devices via /sys/block, and 'Manage networking' which involves checking network device attributes in /sys/class/net. Questions may ask you to explain the difference between /sys and /proc, or to find the SCSI device ID for a disk to use in configuration files.

The CompTIA Linux+ exam often presents scenario-based questions where you must identify the correct path to a device attribute. For example, 'An administrator needs to change the I/O scheduler for the first SATA drive. Which file should they write to?' The answer is /sys/block/sda/queue/scheduler. Another common question type asks about the default filesystem mounted on /sys, it is 'sysfs'. They may also test whether you know that /sys is not persistent storage; writing to /sys does not survive a reboot unless the change is scripted. LPIC-1 exams have included drag-and-drop exercises where you match directories like /sys/bus, /sys/class, and /sys/devices to their descriptions.

Red Hat RHCSA exams are performance-based, meaning you have to actually demonstrate skills in a live environment. A typical task might be: 'Ensure that the second disk (/dev/sdb) uses the deadline I/O scheduler. Make this change persistent across reboots.' You would need to (1) verify the current scheduler by catting /sys/block/sdb/queue/scheduler, (2) write 'deadline' to that file, and (3) create a udev rule or systemd service to reapply the setting after reboot. Another RHCSA task might ask to 'Identify the WWID (World Wide Identifier) of a specific LUN', you would find it in /sys/block/sdX/device/wwid. Without familiarity with /sys, such tasks are impossible to complete under time pressure.

Questions also test conceptual understanding: 'True or False: The /sys directory is stored on the hard drive.' (False.) Or 'Which kernel object is used to export device information to user space?' (kobject.) Some advanced questions from the Red Hat Certified Engineer (RHCE) track involve manipulating driver binding via /sys/bus/pci/drivers/, e.g., unbinding a driver from a device by writing the device bus ID to the 'unbind' file, then binding it to a different driver. Such questions are rare but appear in performance-based exams for senior-level certifications. Overall, any exam that tests Linux device management or system diagnostics will have at least one question directly about /sys, and many more that assume you understand how to navigate it for troubleshooting.

## How it appears in exam questions

Multiple-choice questions: The most common question pattern gives a scenario and asks which file to read or write. For example: 'A system administrator wants to check the current CPU frequency scaling governor. Which file should they examine?' Options might include /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor (correct), /proc/cpuinfo (distractor), /sys/class/cpu/ (nonexistent), etc. Another multiple-choice question: 'After adding a new hard disk, the administrator wants to verify its rotation speed. Which file in /sys provides this information?' Answer: /sys/block/sdb/queue/rotational. Distractors include /proc/partitions, /sys/bus/scsi/devices/, and /dev/sdb.

Scenario-based multiple-choice: You might be given a scenario where a network interface (eth0) is not transmitting data. The question: 'Which file should you read to see the number of transmission errors on eth0?' The correct answer is /sys/class/net/eth0/statistics/tx_errors. Distractors could include /sys/class/net/eth0/operstate (shows link state), /proc/net/dev (shows aggregate statistics but not per-error count as easily), or /sys/class/net/eth0/device/vendor (shows vendor ID). Another scenario: 'A user reports that the cursor moves erratically. Which sysfs path can help you see the input device event number?' Answer: /sys/class/input/mouse0/event, but the exact path depends on the device.

Performance-based / command-line questions (RHCSA style): The exam environment presents a shell prompt, and you must accomplish a task. For instance: 'Configure the system so that the first SCSI disk uses the 'noop' I/O scheduler. Make this change persist across reboots.' The candidate must: (a) echo 'noop' > /sys/block/sda/queue/scheduler, (b) verify it with cat, (c) add a udev rule like 'ACTION=="add", KERNEL=="sda", ATTR{queue/scheduler}="noop"' or a systemd oneshot service. Another performance task: 'Find the WWID of the LUN presented to /dev/sdc and write it to /root/lun_id.txt.' The solution: cat /sys/block/sdc/device/wwid > /root/lun_id.txt.

Troubleshooting questions: 'A USB printer is not working. Which steps can you take to verify that the kernel detected the device?' Correct steps: 'Check /sys/bus/usb/devices/ for a new directory, check /sys/class/usb/printers/, and look at /sys/devices/pci0000:00/... (the USB controller path).' Wrong answers might mention /etc/fstab or /var/log/messages (which is useful but not the kernel interface). Another troubleshooting question: 'After changing a setting in /sys/power/state, the system became unresponsive. Why?' The answer: Writing 'mem' to /sys/power/state puts the system into suspend mode, which might require proper hardware support. Candidates need to know that not all hardware supports S3 sleep.

Comparison questions: 'How does /sys differ from /proc?' The exam expects: /sys exports device model information (kobjects) in a structured hierarchy, while /proc exports process data and system-wide kernel settings. /sys emphasizes one value per file, while /proc often has large multi-value files. /sys is more suitable for hardware enumeration, /proc for process information. Multiple-choice distractors might claim that /proc is for devices and /sys is for processes, reversed.

Finally, drag-and-drop or ordering questions: 'Place the following sysfs directories in order of typical traversal for troubleshooting a USB network adapter.' Steps might be: 1) /sys/bus/usb/devices/ to find the USB device, 2) /sys/class/net/ to find the network interface, 3) /sys/class/net/eth1/device/ to see the driver in use, 4) /sys/bus/pci/drivers/ to check the driver module. These patterns confirm that exam writers assess both declarative knowledge (what is where) and procedural knowledge (how to use it).

## Example scenario

You are a junior system administrator for a small company that runs a Linux web server. The server has two hard drives: a small solid-state drive (SSD) for the operating system and a larger spinning hard disk drive (HDD) for storing customer data. Lately, you have noticed that the server feels sluggish when users upload large files. Your senior colleague suspects the I/O scheduler on the HDD might be set to the wrong algorithm for a traditional spinning drive. They ask you to check the current I/O scheduler for the HDD and, if it is 'cfq', change it to 'deadline' to optimize throughput for the storage workload.

You log in to the server via SSH. First, you need to identify which device name corresponds to the HDD. You run 'lsblk' and see that /dev/sda is the 500GB HDD and /dev/nvme0n1 is the 256GB SSD. Next, you navigate to /sys/block/sda/queue/scheduler. Using 'cat /sys/block/sda/queue/scheduler', you see the output: '[cfq] deadline noop'. The brackets around 'cfq' indicate that it is the currently active scheduler. Now you write 'deadline' to the file using 'echo deadline > /sys/block/sda/queue/scheduler'. You verify the change by reading the file again; this time it shows 'cfq [deadline] noop'. The HDD is now using the deadline scheduler.

But your senior colleague reminds you that this change is temporary, it will revert to cfq after a reboot. To make the change permanent, you need to create a udev rule. You create a file /etc/udev/rules.d/60-scheduler.rules with the content: 'ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="deadline"'. You save the file and reload udev with 'udevadm control --reload-rules'. Now, when the system boots, the rule ensures the HDD uses the deadline scheduler. This entire exercise, identifying the device, reading the current state from /sys, changing it via /sys, and persisting the change, is a textbook use of /sys in a real IT environment. Understanding this flow directly maps to RHCSA performance tasks and CompTIA Linux+ scenario questions.

As a bonus, you also check /sys/block/sda/queue/rotational to confirm that /dev/sda is indeed an HDD. The file returns '1' (rotational). For the SSD you check /sys/block/nvme0n1/queue/rotational and it returns '0'. This verifies your understanding of the hardware. Later, you monitor disk performance using iostat and find that write latency dropped by 20%. Your senior colleague is impressed, and you have just demonstrated real-world Linux device management using sysfs.

## Common mistakes

- **Mistake:** Thinking /sys is a regular directory where you can create, delete, and store files like /home or /tmp.
  - Why it is wrong: /sys is a virtual filesystem managed by the kernel; you cannot create arbitrary files there. Trying to 'touch /sys/test' will fail with 'Read-only file system' or 'Operation not permitted' for most locations. The kernel controls the structure based on hardware.
  - Fix: Understand that /sys is a read-mostly, kernel-generated interface. Only use it to read attributes and write to predetermined control files. Never treat it as user storage.
- **Mistake:** Confusing /sys with /proc and assuming they serve identical purposes.
  - Why it is wrong: While both are virtual filesystems, /proc primarily exposes process information and kernel tuning parameters (e.g., /proc/sys/net/ipv4/...), while /sys exposes the device model (hardware topology, drivers, buses). They have different directory structures and different kernel backends.
  - Fix: Remember the mnemonic: /proc is for 'processes', /sys is for 'system devices'. If you need to check CPU temperature, it's in /sys/class/thermal/, not /proc. If you need to read a process's memory maps, it's in /proc/[pid]/maps.
- **Mistake:** Assuming changes made in /sys are persistent after a reboot.
  - Why it is wrong: Attributes in /sys are memory-based; every change is lost when the system shuts down or reboots. The kernel recreates sysfs from scratch on each boot based on the current hardware and driver state.
  - Fix: Always implement persistence through startup scripts (e.g., /etc/rc.local, systemd units, or udev rules) if you need a configuration to survive reboots. For certification exams, know that writing to /sys alone does not make a change permanent.
- **Mistake:** Trying to write to a read-only attribute file and expecting success.
  - Why it is wrong: Many files in /sys (like 'vendor', 'device', 'modalias') are read-only because they report immutable hardware identifiers. Attempting to write to them returns 'Permission denied' even as root. Some beginners think they can change a device's vendor ID or model by writing to those files, which is incorrect.
  - Fix: Check file permissions using 'ls -l' in /sys. Files with 'r--r--r--' (444) or 'r--r-----' (440) are read-only. Only files with write permission (e.g., 'rw-r--r--' or 'rw-------') are designed for modification. Use 'cat' to read, not 'echo >', unless you are certain the file is writable.
- **Mistake:** Assuming that all device attributes are always present in a fixed path under /sys.
  - Why it is wrong: The exact path to a device attribute depends on the bus, driver, and kernel configuration. For example, a SATA SSD might appear under /sys/block/sda/ while an NVMe SSD appears under /sys/block/nvme0n1/. An old IDE disk would have a different structure. The path may also vary across kernel versions.
  - Fix: Learn to navigate sysfs dynamically. Use commands like 'ls /sys/block', 'ls /sys/class/net', or 'find /sys -name "vendor"' to locate attributes. Tools like 'udevadm info --attribute-walk --name=/dev/sda' can show the full sysfs path for a device.

## Exam trap

{"trap":"The exam asks: 'You need to permanently change the I/O scheduler for /dev/sdb to 'noop'. Which of the following steps is sufficient?' The candidate chooses 'echo noop > /sys/block/sdb/queue/scheduler' alone and marks it as correct.","why_learners_choose_it":"Learners know that writing to the sysfs file changes the scheduler immediately, and they assume that 'permanently' means 'it works right now'. They overlook the fact that the change is lost on reboot. Many beginners have not yet internalized that sysfs is volatile.","how_to_avoid_it":"Always read the question carefully for the word 'permanently' or 'persistently'. If the question asks for a permanent change, the answer must include a udev rule, a modprobe configuration, a systemd unit, or an init script. Only 'echo > /sys/...' is never sufficient for permanence. Some questions might ask which method makes the change 'immediately and persistently', the correct answer is usually both writing to sysfs and configuring a persistence mechanism. On performance exams, you must actually create the persistence rule; on multiple-choice, look for the option that includes both steps."}

## Commonly confused with

- **/sys vs /proc:** /proc is a virtual filesystem that exports process information (like running processes, memory usage) and system-wide kernel parameters (e.g., /proc/sys/). /sys focuses on the device model, hardware topology, drivers, and device-specific attributes. While both are virtual and RAM-based, /proc uses a flat or pseudo-hierarchical structure with many multi-value files, whereas /sys uses a deep, strict hierarchy with one value per file. In exams, distinguishing between them is common. (Example: To see CPU information, you would use /proc/cpuinfo. To change the power management policy for a specific network card, you would use /sys/class/net/eth0/power/control.)
- **/sys vs /sys/fs/cgroup:** /sys/fs/cgroup is the mount point for the cgroup v2 filesystem, which controls resource limits (CPU, memory, I/O) for process groups. It is often mistaken for sysfs because the path starts with '/sys', but it is a completely different filesystem type (cgroup2 vs sysfs). The purpose is different: sysfs is for device enumeration and configuration; cgroupfs is for resource isolation and accounting, commonly used by container runtimes like Docker. (Example: You read /sys/class/thermal/thermal_zone0/temp to check CPU temperature, but you read /sys/fs/cgroup/memory/memory.current to see the current memory usage of a container's control group.)
- **/sys vs /dev:** /dev is the directory containing device nodes (special files) that allow user-space programs to access hardware via block or character I/O operations. /sys provides metadata about those devices, like vendor ID, driver name, power state, but does not itself allow data transfer to the device. You write data to a device through /dev/sda, not /sys/block/sda. In other words, /dev is the door to the hardware, while /sys is the sign on the door describing it. (Example: To copy a file to a USB flash drive, you mount /dev/sdb1 to /mnt and copy files there. To check whether the kernel sees the USB drive as /dev/sdb, you would look in /sys/block/sdb/ to see files like 'size' and 'device/vendor'.)
- **/sys vs /sys/bus:** /sys/bus is a subdirectory within /sys, not a separate concept. However, beginners sometimes think '/sys/bus' is the only relevant part. Actually, /sys contains several important subtrees: /sys/devices (physical topology), /sys/class (functional grouping), /sys/block (block devices), /sys/bus (bus-level grouping), /sys/firmware, /sys/power, etc. Each serves a different purpose for navigation and discovery. (Example: To find all USB devices, you could traverse /sys/bus/usb/devices/. To find all network interfaces, you go to /sys/class/net/. To find a device's PCI location, you go to /sys/devices/pci0000:00/.)

## Step-by-step breakdown

1. **Boot and Kernel Initialization** — When the Linux kernel boots, it enumerates all hardware devices, PCI controllers, USB buses, SCSI hosts, etc. For each device detected, the kernel creates a kobject. The sysfs filesystem is then populated by exporting each kobject as a directory and its attributes as files. The entire hierarchy is built from scratch in memory, reflecting exactly the hardware present at that moment.
2. **Mounting of sysfs** — The init system (typically systemd) mounts the sysfs filesystem on /sys using the command 'mount -t sysfs sysfs /sys'. This mount is defined in /etc/fstab but often happens automatically via the initramfs. Unlike a disk filesystem, sysfs has no block device backing it; it exists only in RAM. After mounting, the root-level directories like /sys/devices, /sys/bus, /sys/class become available.
3. **Navigating the Device Tree** — The /sys/devices subtree mirrors the physical connection topology. For example, a PCI device connected to PCI bus 0, device 0, function 0 will appear as /sys/devices/pci0000:00/0000:00:00.0/. Under this directory, you will find files like 'vendor', 'device', 'irq', 'resource', and subdirectories for functions. To find a specific device, you can start at /sys/devices and walk down using 'ls' and 'cd', but more commonly you use bus or class shortcuts.
4. **Using Bus and Class Symlinks** — Because the device tree can be deep and hard to navigate, sysfs provides symlinks in /sys/bus/ and /sys/class/. For instance, /sys/bus/pci/devices/ contains symlinks to every PCI device in the tree, named by the PCI address. Similarly, /sys/class/net/ contains symlinks to every network interface, making it easy to find eth0 regardless of the underlying bus. These symlinks are not real directories but pointers to the actual device directories in /sys/devices/.
5. **Reading Attributes** — Once you locate the desired device directory, you can read attribute files using standard 'cat' command. For example, 'cat /sys/class/net/eth0/address' returns the MAC address. Each read triggers the kernel's show() method for that attribute, providing up-to-date values. For statistical attributes like 'tx_packets', the kernel populates them from driver counters. This is how network monitoring tools obtain instantaneous statistics.
6. **Writing to Control Attributes** — Some attributes are writable, allowing dynamic configuration. The user writes a value to the attribute file (e.g., 'echo deadline > /sys/block/sda/queue/scheduler'), which triggers the kernel's store() method. The kernel then applies the requested change. Common writable attributes include I/O scheduler, power control (on/auto), backlight brightness, and CPU frequency governor. Writing requires root privilege and the value must be valid for that attribute.
7. **Uevent Generation and Device Changes** — When a device is added or removed (e.g., plugging in a USB flash drive), the kernel emits a uevent, a message over the netlink socket containing details like action (add/remove), devpath (the sysfs path), and subsystem. udev listens for these events and can trigger actions such as creating device nodes, loading firmware, or running custom scripts. sysfs is the source of the device paths used in these events.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/sys