Linux Device Management permissions Tilt--mem, Proc, DEVFS, Sysfs, Udev (bottom)

Jack: What does the device management mechanism of Linux implement look like, Kinky dragon?

Me: In the 2.4 kernel, the main solution is DEVFS.

Jack: I know. In 2.6, DEVFS has been replaced by Udev.

Me: This is not accurate, is a layman to see the lively saying.

Jack: What do you say?

Me: Let me tell you about the origins of the proc file system. After listening, you will understand.

Jack:proc file system? Across the.

I: In a long long time ago, all the code of the Linux kernel is dead, if you want to modify some of the parameters, you have to manually modify the source code, and then recompile, re-write the floppy disk, run again. A long time ago, a file--/dev/mem appeared in the Unix/dev directory. This is a special (variant) device file that can change the memory of the entire kernel by reading and writing the file (from the user process). From then on, the kernel's memory can be dynamically modified without the need to stop the complex process of modifying kernel code, recompiling, re-writing floppy disks, and restarting these columns.

Jack: And then, the Prince and the Princess of the Blessed living together?

Me: Go to hell. Linux kernel developers from/dev/mem This variant of the device file tasted the sweetness, it is out of hand. They then set up a/proc directory and created the proc file system at the same time. Files in the/proc directory are variable-shaped files that do not exist on disk, but are dynamically established during access, and exist in Ramfs. These files were primarily a statistical and dynamic modification of memory usage in the early days, and later, the kernel designer's appetite became more and more difficult to meet. All the ideas that they think are easy to manage should be included in this directory, and/proc is no longer limited to memory information, even--SYSFS external device management information.

Jack: What's the relationship with this DEVFS?

Me: Devfs is growing up in this context. is a generalization or mutation of the proc file system. However, DEVFS has many fatal flaws, leading to Devfs's author's inability to resolve the ability and confidence, and finally, the decision to announce failure and utter abandonment. Then, in the kernel of Linux2.5, try to build a Sysfs file system. This file system is hooked up under/sys.

What is the fatal flaw of JACK:DEVFS?

Me: This question is already a lot online, just Google a bit.

Jack: So what's going on with Udev?

Me: Don't be anxious first. Let me finish the Sysfs, and you listen to udev fully understand. Compared to DEVFS, Sysfs is a set of integrated equipment management models. SYSFS's descriptive capabilities are not confined to working external devices, including external buses (PCI bus, etc.). The root directory of files that are hooked up to the/sys directory is categorized by type, not hierarchy. including/sys/bus,/sys/block,/sys/class and so on.

Jack: So, how did Udev get here?

Me: The Sysfs file system can visually react to information about the bus and device that is joined to the computer (via the Kobject object). However, it is only a manifestation and reaction, and cannot be like DEVFS, when generating a device file (regardless of the device is not in), the device is directly loaded into the driver (in fact, this is not necessary). If you want to intelligently control the management of external devices, you also need a task, a professional tool. In Devfs, the job is a kernel thread. Udev, on the other hand, fires the function by waiting for events caused by the kernel's registered device hot-swapping.

Jack: So what's the advantage?

Me: The biggest advantage of this is that the load on the kernel is reduced and the work is transferred to the user process.

Jack: But, from the CPU point of view, is not the same to work? The overall load does not degrade.

Me: Yes. From the CPU point of view, the load is not reduced, butDEVFS is responsible for the work of the operating system is not the core of the work, this work can be transferred to the user space is the best. The benefits are at least three points:

1. If the thread (or process) crashes, the user space crash is much less harmful to the overall system than the crash in the kernel space (especially within some financial systems).

2, the thread running in the kernel space will encounter a lot of synchronization and mutual exclusion problems, it will be difficult to design, if you want to add a function in the kernel (especially the core function), then the difficulty will be exponential growth.

3, the kernel is not a garbage dump, can not throw everything, even if it is not bad. However, if the foundation is broken, 10 years from now, the whole system will be left with a terrible problem. This phenomenon is very serious in the major internet companies.

Jack: So,Udev and DEVFS are not at all the same level of concept . Devfs not only includes a file system mechanism, but also includes monitoring of external devices and working threads. And Udev is just a tool to work with SYSFS.

Me: I can understand that. So, I said, "Devfs was replaced by Udev" is a layman's view of the lively.

Jack: Can you tell me the difference between the DEVFS and the Udev implementation?

Me: No. DEVFS has been completely discarded in the 2.6 kernel, and I have no knowledge of its implementation. About Sysfs+udev can simply talk about its principle. The most important is 3 structural bodies: Kobjects, ksets, subsystems. Among them, when a kobjects structure object is generated (the driver engineer implementation) will occur two important things: 1, in the/sys/directory will have the corresponding folder. 2, generate a HotPlug event, when an external device is plugged/unplugged, the kernel will take this time to proactively notify the process of user space (Udev. Essentially, a hotplug is a signal or a soft interrupt mechanism, and the signal is also a soft interrupt in its broadest sense. Compared to Kobjects's high abstraction, Kset is more specific. How specific to what extent? All kobjects with the same attribute are divided into a kset. As to what kind of equipment has the same kobjects properties, the drive engineering is self-judged. and a device specifically how to join Linux, is not the device model should consider the problem, but the implementation of the driver engineer. The device model simply gives a framework that all devices are required to comply with, but not a hands-on drive engineer to write drivers.

Linux Device Management permissions Tilt--mem, Proc, DEVFS, Sysfs, Udev (bottom)