Sysfs and Device Management

As devices initialize, the practice is to use a certain data structure, a kobject, to track its existence. Kobjects aren’t objects in the Yourdon and Coad3 sense of the word; they’re data structures used throughout the kernel that are exposed through the sysfs file system mounted at /sys. If your desktop is running a 2.6 kernel and doesn’t have a file system mounted at /sys, do the following to make this file system available:

# mkdir /sys
# mount -t sysfs none /sys
$ cd /sys

One of the purposes of kobjects when they were introduced was creating a uniform, dependable way for a process in userland to see the device drivers loaded by the kernel. Their use has been expanded over the years to include keeping track of more types of kernel-level data. The notion of kobjects makes it very easy for devices to register and be queried from userland in order to create the device nodes files in the /dev directory, and that is why kobjects are important in the boot-up process.

The typical desktop machine has a Linux distribution designed to work on some computer, but not necessarily your computer. During the boot-up process, the kernel probes the hardware and attempts to load drivers for that hardware. When those drivers load, they create a kobject in their tracking data structures that is registered by the kernel. The kobject is a data structure exposed in the sysfs file system. In user space, another process runs, called udevd, which inspects the sysfs file system to create the necessary entries in /dev for the device drivers that have been loaded. This is how the /dev file system gets populated with all those device nodes without your direct intervention. This process ensures that the /dev directory has device nodes for all the drivers-and that means the hardware is accessible to the system for use.

Most embedded systems have a fixed set of devices that doesn’t change; the overhead of the sysfs file system and udevd is wasteful, because the set of device nodes necessary could be created once and stored on the root file system. This is worth mentioning at this point because it’s important to understand what happens during the startup process. When the book discusses reducing boot time and root file system size, udev and the /dev and /sys directories are low-hanging fruit.

Device nodes are an interesting concept if you’re new to embedded Linux. Linux has a Unix heritage, in that a file establishes the semantics for how things communicate. A hardware device like a USB drive, mouse, or serial port uses a file for communication as well; however, these aren’t real files but rather placeholders in the file system (device node files) that look like files. They serve as proxies for communicating with device drivers in the
kernel. By writing or reading these things that look like files, the device driver calls functions that handle getting data from userland (the result of a write) or sending data to userland (the result of a read).

Source of Information : Pro Linux Embedded Systems