sysfs and devtmpfs

sysfs and devtmpfs

 

Question:

Ulrich Dangel explains verywell the difference between devtmpfs and udev.

What about sysfs?

I understand that the kernel uses sysfs toexport device nodes to user space to be used by udev. So devtmpfs and sysfs arethe same? If yes, why do they use different names? If no, what is the realdifference between sysfs and devtmpfs?

 

 

 

Answen:

No. Sysfs does not contain device nodes.Sysfs mainly contains files that provide information about devices, as well assome files that allow processes to control how devices operate. But for themost part devices cannot beused through what sysfs provides.

Let's take ahard disk, for example. There's a directory for it somewhere under /sys/devices, with a path that depends on how it's connected to the computer(e.g. /sys/devices/pci0000:00/… for a disk connected to a controller that'sconnected to the computer's primary PCI bus). In that directory, you can findvarious information such as its size, whether it's removable, its power state,etc. There are subdirectories for partitions as well. But there's nothing inthere that provides access to the content of the disk. Elsewhere in /sys, there aresymbolic links to the directory corresponding to that disk: in /sys/block, in /sys/class/block, etc. But still nothing to access thecontent of the disk.

In /dev, the entry forthe disk is a special file — a blockdevice. This file allows processes to read and write the content of the disk.(Though for a disk that usually doesn't happen; instead the content of the disk— or of a partition — is mounted, so the kernel is accessing the device,processes don't.)

 

Device filesallow some operations other than reading and writing content to be madethrough ioctl. It would be possible to provide allthe information and control interfaces that sysfs provides through ioctl on thedevice file. However this would be less convenient for several reasons:

1、  With separate files in /sys, permissionscan be set on a fine-grained basis. With a single file per device in /dev, it's all ornothing.

2、  Separate files can be read and writteneasily by applications. You can just use cat or echo. With ioctl, it's a lot harder: there'sno shell interface, often no interface in other high-level languages.

3、  With ioctl, the command has to beencoded in a number rather than a name, and the format of the arguments has tobe defined at a binary level. Using names and simple text formats makes iteasier to write software.

 

Going in theother direction, it would be possible to provide access to the device contentvia a file in sysfs. But this would require extra work in the kernel: sysfs isdesigned primarily to serve small files and symbolic links, and withoutthe ioctl supportthat existing applications expect. I don't think there would be a significantbenefit to expanding sysfs to support existing device types, hence the continuedexistence of device files.

 

Sysfs isautomatically populated by the kernel, reflecting the actually availabledevices in real time.

l  The meaning of a file in sysfs comesfrom its path, which is chosen by the driver that provides that file. 

l  /dev works differently:the meaning of a file comes from the device file's type (block or character)and its major and minor numbers (that's what ls -l lists instead of the file size fora device).

 

Dynamic /dev that reflects connecteddevices in real time

Traditionally, /dev wasstatic, with device files created during system installation; but that doesn'twork so well when devices can be hotplugged, hence the wish for a dynamic /dev thatreflects connected devices in real time.

 

Linux has gonethrough several iterations of a dynamic /dev. Linux 2.4 has devfs, where the kernel automatically createdentries to reflect connected devices. But that was notso nice, because it hard-coded device naming and permission policies into thekernel, so it was replaced by the userland program udev to manage policy, and /dev on asimple tmpfs filesystem (an in-memory filesystem with no special meaning to thekernel). And then devfs made a partial comeback, with devtmpfs, which is an instance of tmpfs whereentries for available devices are automatically created by the kernel, but udevdoes all the management it wants on top of that.

 

 

 

 

 

 

 

 

From: http://unix.stackexchange.com/questions/236533/sysfs-and-devtmpfs