Managing System Devices With the udev Device Manager

Overview of how the udev device manager discovers hardware, manages device nodes, and integrates with systemd on Oracle Linux.

The udev device manager runs as a systemd service to help provide software with predictable and managed access to system devices exposed by the kernel. Typically, udev manages the permissions of device nodes, creates symbolic links in the /dev/ directory to make device names more predictable and easier to identify, or renames network interfaces.

The udev device manager dynamically creates or removes device node files at boot time. When creating a device node, udev reads the device's /sys directory for attributes such as the label, serial number, and bus device number.

udev can use persistent device names to guarantee consistent naming of devices across reboots, regardless of their order of discovery. Persistent device names are especially important when using external storage devices.

udev also handles device driver events that are triggered by the kernel and uses the rules defined in its configuration to trigger particular actions. For example, if a USB storage device is connected to the system, the kernel notifies udev and udev notifies the appropriate handler so that the device can be mounted. Also, if a network cable is connected to a network interface card, the kernel notifies udev of the state change and udev notifies NetworkManager so that the appropriate action can take place to connect to the network.

The configuration file for udev is /etc/udev/udev.conf, in which you can define the udev_log logging priority, which can be set to err, info and debug. The default value is err. Further configuration of rules used by udev are handled in individual rules files in /etc/udev/rules.d/.

For more information, see the udev(7) manual page.

udev is a component of systemd. For additional background, consult the release-specific systemd guides.

For more information about systemd concepts used by udev across Oracle Linux releases, see Managing the System With systemd.

For more information about the kernel virtual file systems and device driver modules, use the following release-specific resources.

For more information about the kernel virtual file systems and device driver modules across Oracle Linux releases, see Managing Kernels and System Boot on Oracle Linux.

About Device Files

Explains how Oracle Linux represents hardware as device files, including block, character, and pseudo devices.

The /dev directory contains device files or device nodes that provide access to peripheral devices such as hard disks, to resources on peripheral devices such as disk partitions, and pseudo devices such as a random number generator.

The /dev directory has several subdirectory hierarchies, each of which holds device files that relate to a certain type of device. However, the contents of these subdirectories are implemented as symbolic links to corresponding files in /dev. Thus, the files can be accessed either through the linked file in /dev or the corresponding file in the subdirectory.

Using the ls -l /dev command lists files, some of which are flagged as being either type b (for block) or type c (for character). These devices have an associated pair of numbers that identify the device to the system.

ls -l /dev
total 0
crw-r--r--. 1 root root     10, 235 Aug 20 08:36 autofs
drwxr-xr-x. 2 root root         240 Sep 20 07:37 block
drwxr-xr-x. 2 root root         100 Aug 20 08:36 bsg
drwxr-xr-x. 3 root root          60 Nov  4  2019 bus
lrwxrwxrwx. 1 root root           3 Aug 20 08:36 cdrom -> sr0
drwxr-xr-x. 2 root root        2720 Sep 20 07:37 char
crw-------. 1 root root      5,   1 Aug 20 08:36 console
lrwxrwxrwx. 1 root root          11 Aug 20 08:36 core -> /proc/kcore
drwxr-xr-x. 3 root root          60 Nov  4  2019 cpu
crw-------. 1 root root     10,  62 Aug 20 08:36 cpu_dma_latency
drwxr-xr-x. 7 root root         140 Aug 20 08:36 disk
brw-rw----. 1 root disk    253,   0 Aug 20 08:36 dm-0
brw-rw----. 1 root disk    253,   1 Aug 20 08:36 dm-1
brw-rw----. 1 root disk    253,   2 Aug 20 08:36 dm-2
lrwxrwxrwx. 1 root root          13 Aug 20 08:36 fd -> /proc/self/fd
crw-rw-rw-. 1 root root      1,   7 Aug 20 08:36 full
crw-rw-rw-. 1 root root     10, 229 Aug 20 08:36 fuse
crw-------. 1 root root     10, 228 Aug 20 08:36 hpet
drwxr-xr-x. 2 root root           0 Aug 20 08:36 hugepages
crw-------. 1 root root     10, 183 Aug 20 08:36 hwrng
lrwxrwxrwx. 1 root root          12 Aug 20 08:36 initctl -> /run/initctl
drwxr-xr-x. 3 root root         220 Aug 20 08:36 input
crw-r--r--. 1 root root      1,  11 Aug 20 08:36 kmsg
lrwxrwxrwx. 1 root root          28 Aug 20 08:36 log -> /run/systemd/journal/dev-log
brw-rw----. 1 root disk      7,   0 Sep 23 01:28 loop0
crw-rw----. 1 root disk     10, 237 Sep 20 07:37 loop-control
drwxr-xr-x. 2 root root         120 Aug 20 08:36 mapper
crw-------. 1 root root     10, 227 Aug 20 08:36 mcelog
crw-r-----. 1 root kmem      1,   1 Aug 20 08:36 mem
crw-------. 1 root root     10,  59 Aug 20 08:36 memory_bandwidth
drwxrwxrwt. 2 root root          40 Nov  4  2019 mqueue
drwxr-xr-x. 2 root root          60 Aug 20 08:36 net
crw-------. 1 root root     10,  61 Aug 20 08:36 network_latency
crw-------. 1 root root     10,  60 Aug 20 08:36 network_throughput
crw-rw-rw-. 1 root root      1,   3 Aug 20 08:36 null
crw-------. 1 root root     10, 144 Aug 20 08:36 nvram
drwxr-xr-x. 2 root root         100 Aug 20 08:36 ol_ca-virtdoc-oltest1
crw-r-----. 1 root kmem      1,   4 Aug 20 08:36 port
crw-------. 1 root root    108,   0 Aug 20 08:36 ppp
crw-rw-rw-. 1 root tty       5,   2 Oct  7 08:10 ptmx
drwxr-xr-x. 2 root root           0 Aug 20 08:36 pts
crw-rw-rw-. 1 root root      1,   8 Aug 20 08:36 random
drwxr-xr-x. 2 root root          60 Nov  4  2019 raw
lrwxrwxrwx. 1 root root           4 Aug 20 08:36 rtc -> rtc0
crw-------. 1 root root    251,   0 Aug 20 08:36 rtc0
brw-rw----. 1 root disk      8,   0 Aug 20 08:36 sda
brw-rw----. 1 root disk      8,   1 Aug 20 08:36 sda1
brw-rw----. 1 root disk      8,   2 Aug 20 08:36 sda2
brw-rw----. 1 root disk      8,  16 Aug 20 08:36 sdb
brw-rw----. 1 root disk      8,  17 Aug 20 08:36 sdb1
crw-rw----. 1 root cdrom    21,   0 Aug 20 08:36 sg0 

Block Devices

Block devices enable random access to data, seeking media for data, and typically buffers data while data is being written or read. Examples of block devices include hard disks, CD-ROM drives, flash memory, and other addressable memory devices.

Character Devices

Character devices enable the streaming of data to or from a device. The data isn't typically buffered nor is random access granted to data on a device. The kernel writes data to or reads data from a character device 1 byte at a time. Examples of character devices include keyboards, mice, terminals, pseudo-terminals, and tape drives. tty0 and tty1 are character device files that correspond to terminal devices so users can log in from serial terminals or terminal emulators.

Pseudo-Terminal Character Devices

Pseudo-terminal secondary devices emulate real terminal devices so they can interact with software. For example, a user might log in to a terminal device such as /dev/tty1, which then uses the pseudo-terminal primary device, /dev/pts/ptmx, to interact with an underlying pseudo-terminal device. The character device files for pseudo-terminal secondary and primary devices are in the /dev/pts directory, as shown in the following example:

ls -l /dev/pts
total 0
crw--w----. 1 guest tty  136, 0 Mar 17 10:11 0
crw--w----. 1 guest tty  136, 1 Mar 17 10:53 1
crw--w----. 1 guest tty  136, 2 Mar 17 10:11 2
c---------. 1 root  root   5, 2 Mar 17 08:16 ptmx

Some device entries, such as stdin for the standard input, are symbolically linked through the self subdirectory of the proc file system. The pseudo-terminal device file to which they point depends on the context of the process.

ls -l /proc/self/fd/[012]
lrwx------. 1 root root 64 Oct  7 08:23 /proc/self/fd/0 -> /dev/pts/0
lrwx------. 1 root root 64 Oct  7 08:23 /proc/self/fd/1 -> /dev/pts/0
lrwx------. 1 root root 64 Oct  7 08:23 /proc/self/fd/2 -> /dev/pts/0

null, random, urandom, and zero Character Devices

Character devices, such as null, random, urandom, and zero are examples of pseudo devices that provide access to virtual functionality implemented in software rather than to physical hardware.

/dev/null is a data sink. Data that you write to /dev/null effectively disappears but the write operation succeeds. Reading from /dev/null returns EOF (end-of-file).

/dev/zero is a data source of an unlimited number of 0-value bytes.

/dev/random and /dev/urandom are data sources of streams of pseudo-random bytes. To maintain high-entropy output, /dev/random blocks if its entropy pool doesn't contain sufficient bits of noise. /dev/urandom doesn't block and, therefore, the entropy of its output might not be as consistently high as that of /dev/random. However, neither /dev/random nor /dev/urandom are considered to be random enough for the purposes of secure cryptography such as military-grade encryption.

You can find out the size of the entropy pool and the entropy value for /dev/random from virtual files under /proc/sys/kernel/random:

cat /proc/sys/kernel/random/poolsize
4096
cat /proc/sys/kernel/random/entropy_avail
3467

For more information, see the null(4), pts(4), and random(4) manual pages.