[Buildroot] Device files and Buildroot

[Thomas Petazzoni <thomas.petazzoni@free-electrons.com>]

Le Sat, 3 Dec 2011 01:25:41 +0100,
Aleksander Dutkowski <adutkowski@gmail.com> a ?crit :

> "System configuration --> Custom script to run before creating
> filesystem image" input is for specify a PATH to bash script.
> You you must simply create script, fill with mknod commands (remember
> - mknod can be ran only by root! so do 'sudo mknod')

No, no, no and no ! I'm sorry but this is totally horrible and is
definitely not the way of doing things with Buildroot.

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/<yourcompany>/<yourproject>/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.

So, no, do *NOT* ever use the post-build script to create device files.
Just understand how those device files work and the different mode
Buildroot provides to handle them.

If you need precisions or have questions on this topic, don't hesitate
to ask. We have many people on the list ready to answer your questions.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com