"The __deprecated marker is quite useful in highlighting the remnants of old APIs that want removing. However, it is quite normal for one or more years to pass, before the (usually ancient, bitrotten) code in question is either updated or deleted," explained Jeff Garzik, posting a small patch to make it possible to silence "warning: 'foo' is deprecated" type messages.

Andrew Morton wasn't impressed, suggesting, "Sigh. Can't we just fix the dud code? Or mark it BROKEN and see what happens?" Linus Torvalds added, "I think removing __deprecated is the better option. Quite frankly, some people add '__deprecated' *way* too eagerly." Jeff agreed that __deprecated is over used, "__deprecated has spread to just about every API that people don't consider fresh and up-to-date." He then added ,"like I noted in the patch description, rewriting grotty ISA/MCA/etc. probe code is a thankless, boring task that few are crazy enough to attempt :) As you can see from the patch flood recently I /have/ been working through the dud code, but it will still take years. The changes required for each are on average ~200 LOC changed, if not more."

"After recent discussions on LKML and a general dissatisfaction at the current printk() kernel-message logging interface, I've decided to write down some of the ideas for a better system," began Vegard Nossum, defining his proposed message logging API for the Linux kernel. He noted that what he was proposing was both backwards compatible with existing logging mechanisms, as well as extensible. Vegard described his proposed kprint() interfaces and their implementations, summarizing, "this scheme is obviously much more complex than the printk() is today. But at the same time, it is also much more powerful, extensible, and clearly/cleanly defined." He described one of the benefits:

"The kprint() and its log-level variants are implemented as macros in order to be able to transparently pass extra information into the main kprint() machinery. As an example, it might happen that an extra feature is added that prepends the current file and line (the __FILE__ and __LINE__ macros) to the message, but in such a way that it can be discarded at run-time, or recorded along with the messages. Additionally, this would allow the compiler to completely optimize out calls that are below a certain log-level severity level."

The proposal generated a lengthy discussion, but there was no indication as to whether or not it would be something that would ultimately be merged into the mainline kernel.

DragonFlyBSD founder Matthew Dillon [interview] posted an update on his syslink protocol which he defined as, "a message based protocol that can devolve down into almost direct procedure calls when two localized resources talk to each other." The syslink API will be used to talk to both local resources on the same node as well as to remote resources on a different node. Earlier documentation further explained the networking nature of the protocol, "the Syslink protocol is used to glue the cluster mesh together. It is based on the concept of reliable packets and buffered streams. Adding a new node to the mesh is as simple as obtaining a stream connection to any node already in the mesh, or tying into a packet switch with UDP." In another email Matthew explained how various DragonFlyBSD nodes utilize Syslink to automatically establish the optimal physical route.

In his recent email, Matthew described the latest Syslink issue he has solved, "in order to transport requests across a machine boundary (that is, outside the domain of a direct memory access), it is necessary to assign a unique identifier to the resource." He detailed how he had originally planned to rework dozens of major system structures to use the syslink API, but instead will now "rework JUST the reference counting methodology used in these resource structures." The end result is "a common ref counting API and a little structure that includes a 64 bit unique sysid, red-black tree node, the ref count, and a pointer to a resource type structure (e.g. identifying it as a vnode, vm object, or whatever). When any of the above resources are allocated, they will be indexed in a Red-Black tree. In other words it will be possible to identify every single resource in the system by traversing the red-black tree". He goes on to summarize, "and that, folks, gives us the building blocks we need to represent resources in a cluster. This also means I don't have to rewrite the APIs. Instead I can simply write new RPC APIs for accesses made via syslink ids and, poof, now all of a system's resources will become accessible remotely, with only modest effort."

Announcing the third version of his syslets subsystem patches [story], Ingo Molnar [interview] noted that he has implemented many fundamental changes to the code including the introduction of threadlets, "'threadlets' are basically the user-space equivalent of syslets: small functions of execution that the kernel attempts to execute without scheduling. If the threadlet blocks, the kernel creates a real thread from it, and execution continues in that thread. The 'head' context (the context that never blocks) returns to the original function that called the threadlet." As threadlets are only moved into a separate thread context if they block, Ingo refers to them as 'optional threads'. He also describes them as 'on-demand parallelism', "user-space does not have to worry about setting up, sizing and feeding a thread pool - the kernel will execute the workload in a single-threaded manner as long as it makes sense, but once the context blocks, a parallel context is created. So parallelism inside applications is utilized in a natural way."

Ingo goes on to note that the syslet code and API has been significantly enhanced in this latest release, "the v3 code is ABI-incompatible with v2, due to these fundamental changes." He adds, "syslets (small, kernel-side, scripted 'syscall plugins') are still supported - they are (much...) harder to program than threadlets but they allow the highest performance. Core infrastructure libraries like glibc/libaio are expected to use syslets. Jens Axboe's FIO tool already includes support for v2 syslets, and the following patch updates FIO to the v3 API".