New LWN Articles About the Kernel (Linux)
-
User trace events, one year later
The kernel has a well-developed mechanism for the control of tracing of events in kernel space. Developers often want to be able to trace user-space activity as well, using the same interfaces, but that mode is rather less well supported. One year ago, an attempt to add an API for the control of user-space trace events ran into trouble and has never been fully enabled. Now, Beau Belgrave is back with a reworked API that may finally result in this mechanism becoming generally available.
User-space trace events, like those in the kernel, tend to be inactive most of the time; nobody is listening, so no data should be generated. In the kernel, inactive tracepoints are patched out of the binary entirely, but that sort of run-time patching is not readily available in user space. So user-space code must actually check whether a given trace event is enabled and, if so, produce the requisite data. Since any given event is almost certainly inactive, that check should be as fast as possible.
-
An operation for filesystem tucking
As a general rule, the purpose behind mounting a filesystem is to make that filesystem's contents visible to the system, or at least to the mount namespace where that mount occurs. For similar reasons, it is unusual to mount one filesystem on top of another, since that would cause the contents of the over-mounted filesystem to be hidden. There are exceptions to everything, though, and that extends to mounted filesystems; a "tucking" mechanism proposed by Christian Brauner is designed to hide mounted filesystems underneath other mounts — temporarily, at least.
Brauner's cover letter describes the intended use case in great detail; the text below is an attempt to boil that discussion down a bit. His explanation leans heavily on the concepts of shared subtrees and mount propagation; a review of this article provides some context that may make the description easier to follow.
-
The trouble with MODULE_LICENSE() in non-modules
The kernel's hierarchical maintainer model works quite well from the standpoint of allowing thousands of developers to work together without (often) stepping on each others' toes. But that model can also make life painful for developers who are trying to make changes across numerous subsystems. Other possible source of pain include changes related to licensing or those where maintainers don't understand the purpose of the work. Nick Alcock has managed to hit all of those hazards together in his effort to perform what would seem like a common-sense cleanup of the kernel's annotations for loadable modules.