With Buildroot, you have four ways of managing the device files in /dev. The mechanism used to manage device files is configured from System configuration -> /dev management. The four ways are :
* Static using device table. In this case the "System configuration -> Path to the device tables" option gives a space-separated list of files, each of which containing a list of devices to create at build time in the root filesystem. By default, this list is defined to just the target/generic/device_table_dev.txt, which creates some basic device files. Those device files are created at *build* time and are statically present in the root filesystem image generated by Buildroot. All basic devices such as /dev/console, /dev/null and al. are already present in the default device table. If you are in this mode and want to add more device files, then you should add them to target/generic/device_table_dev.txt, or better, create your own additional device table in board///device_table.txt, and add it to the space-separated list in "System configuration -> Path to the device tables".
* Dynamic using devtmpfs only. Devtmpfs is a virtual filesystem implemented in the Linux kernel that can be mounted in /dev. The kernel will automatically create/remove device files from this filesystem as devices appear/disappear from the system. devtmpfs exists in the Linux kernel since 2.6.32. When this option is selected *and* Buildroot is responsible for building the kernel, then Buildroot ensures that the kernel is built with the appropriate options to make devtmpfs work. When Buildroot is *not* responsible for building the kernel (the user does it on its own), then the user is responsible for making sure that CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT are both enabled in the kernel configuration. When this mode is used, no static device files are created in the root filesystem: the device files are automatically created at boot time by the kernel.
* Dynamic using mdev. This is exactly like with 'devtmpfs' (i.e, devtmpfs is required for this mode to work), but Buildroot adds the mdev utility into the mix. mdev is an utility bundled with Busybox which gets executed when the kernel notifies that a device has been added or removed from the system. Compared to a pure 'devtmpfs' solution, it allows to execute arbitrary applications or shell scripts when devices appear/disappear. mdev behaviour can be configured from /etc/mdev.conf, refer to the Busybox documentation for more details. Since this case relies on devtmpfs, there are no static device files created in the root filesystem, and no device table is used.
* Dynamic using udev. This is also exactly like with 'devtmpfs' (i.e, devtmpfs is required for this mode to work), but Buildroot adds the udev daemon into the mix. udev is the "device event manager" used in all Linux desktop and server systems and can be seen as a "full-featured" mdev. It is more configurable, provides a library called libudev to allow applications to query for which devices are available, etc.
mdev -s is to be run during boot to scan /sys and populate /dev.
Bare mdev is a kernel hotplug helper. To activate it: echo /sbin/mdev >/proc/sys/kernel/hotplug
It uses /etc/mdev.conf with lines [-][ENV=regex;]...DEVNAME UID:GID PERM [>|=PATH]|[!] [@|$|*PROG] where DEVNAME is device name regex, @major,minor[-minor2], or environment variable regex. A common use of the latter is to load modules for hotplugged devices: $MODALIAS=.* 0:0 660 @modprobe "$MODALIAS"
If /dev/mdev.seq file exists, mdev will waitfor its value to match $SEQNUM variable. This prevents plug/unplug races. To activate this feature, create empty /dev/mdev.seq at boot.
If /dev/mdev.log file exists, debug log will be appended to it.