In Linux sysfs, a network interface is reachable both as /sys/class/net/<name> and as a path somewhere under /sys/devices. How is sysfs organised, and which of those two locations is the canonical one?

## Sysfs is the kernel's object graph Procfs grew organically and mixes process information with statistics and tunables. Sysfs was introduced to do one thing cleanly: expose the kernel's driver model — devices, drivers, buses and classes — as a filesystem, with a strict convention of one attribute per file. It is mounted at /sys, its filesystem type is `sysfs`, and like procfs it stores nothing; each attribute file is backed by a pair of kernel functions that produce or consume a value. One visible difference from procfs is the reported size: sysfs attributes normally report 4096 bytes, one page, because that is the buffer a single attribute is expected to fit in, whereas most procfs files report 0. ## The canonical tree and the views **/sys/devices** is the real hierarchy. It is organised by how hardware is actually attached, so a physical NIC appears at a path built from its bus and address, something like `/sys/devices/pci0000:00/0000:00:1f.6/net/eth0`, and virtual devices live under `/sys/devices/virtual/`. Every device object appears exactly once here. The other top-level directories are indexes into it: - **/sys/class/** groups by functional class, regardless of how the device is attached: `net`, `block`, `tty`, `power_supply`, `thermal`. This is the view you almost always want, because you know you are looking for a network interface long before you know which slot it is in. - **/sys/block/** lists block devices, with partitions as subdirectories of their parent disk. - **/sys/bus/** groups by bus type — `pci`, `usb`, `platform` — and under each you find `devices/` and `drivers/`, which is how you see which driver is bound to which device. That these are views rather than copies is easy to demonstrate: ``` $ readlink -f /sys/class/net/lo /sys/devices/virtual/net/lo ``` So the answer to "which is canonical" is /sys/devices; the class view is a convenience layer, and both paths lead to exactly the same kernel object with the same attribute files. ## One value per file Inside a device directory you find small files, each holding a single value: ``` $ cat /sys/class/net/lo/mtu 65536 $ cat /sys/class/net/lo/address 00:00:00:00:00:00 ``` This is a deliberate contrast with procfs, where a single file such as /proc/meminfo dumps dozens of key/value pairs and every consumer has to write a parser. The sysfs rule means a shell script can read a value with `cat` and no parsing at all, and a program can read it with a single small read. Some attributes are writable, and writing changes kernel state immediately in the same way a /proc/sys write does — for example the queue settings under a block device's `queue/` directory, or interface attributes exposed by a driver. Nothing about the write is persisted, so anything you want to survive a reboot has to be re-applied at boot, by the device manager's rules or by a service. Almost every device directory also contains a `uevent` file. Uevents are the messages the kernel emits when devices appear, disappear or change state, and the userspace device manager listens for them to create device nodes under /dev and to apply naming and permission rules. This is the link between the sysfs object model and the /dev tree: sysfs describes the device, /dev provides the character or block node you actually open. ## What sysfs is not Two boundaries are worth stating because they are commonly blurred. Sysfs is not where kernel tunables live — those are in /proc/sys, reached through the sysctl command. And several other virtual filesystems are conventionally *mounted under* /sys without being sysfs: /sys/fs/cgroup is a separate filesystem type, and /sys/kernel/debug is debugfs, an unstable debugging surface with no interface guarantees. A path starting with /sys therefore does not by itself imply you are looking at a sysfs attribute. ## Why an interviewer asks This question separates a candidate who has explored a machine from one who has only memorised paths. The useful takeaway is the model: one canonical tree by physical topology, several symlinked views by function, one value per file, writes that take effect now and persist never. With that model you can find things on hardware you have never seen before, which is the actual skill being tested.