They are compiler hints for GCC. They're used in conditionals to tell the compiler if a branch is likely to be taken or not. It can help the compiler laying down the code in such a way that's optimal for the most frequent outcome.
They are used like this:
if (likely(some_condition)) {
// the compiler will try and make the code layout optimal for the case
// where some_condition is true, i.e. where this block is run
most_likely_action();
} else {
// this block is less frequently used
corner_case();
}
It should be used with great care (i.e. based on actual branch profiling results). A wrong hint can degrade performance (obviously).
Some examples of how the code can be optimized are easily found by searching for GCC __builtin_expect
. This blog post gcc optimisation: __builtin_expect for example details a disassembly with it.
The kind of optimizations that can be done is very processor-specific. The general idea is that often, processors will run code faster if it does not branch/jump all over the place. The more linear it is, and the more predictable the branches are, the faster it will run. (This is especially true for processors with deep pipelines for example.)
So the compiler will emit the code such that the most likely branch will not involve a jump if that's what the target CPU prefers, for instance.
Debian has a release maturity model, where Unstable, Sid, is where all the new stuff goes in. If it sticks, then Unstable becomes Testing, in which nothing can be added during testing. This typically lasts 1.5 - 2 years. If no problem at that point, Testing becomes the new Stable release.
Security updates are made to Stable first, then to Testing.
Debian Stable is notoriously stable, and notoriously behind the times, but very reliable for servers.
Ubuntu came along and said: we take Debian Unstable, make it more stable, add all the latest gadgets, drivers, etc, and release it.
Ubuntu then works at the security updates, package updates, etc, for their Ubuntu releases.
Note that I gladly use Ubuntu on the desktop, but I stick to Debian Stable for servers.
Makes sense?
Best Answer
Meta-answer: All the raw stuff happening to the Linux kernel goes through lkml (the Linux kernel mailing list). For explicative summaries, read or search lwn (Linux weekly news).
Answer: From The new way of ioctl() by Jonathan Corbet:
Follows an explanation of the patch that introduced
unlocked_ioctl
andcompat_ioctl
into 2.6.11. The removal of theioctl
field happened a lot later, in 2.6.36.Explanation: When
ioctl
was executed, it took the Big Kernel Lock (BKL), so nothing else could execute at the same time. This is very bad on a multiprocessor machine, so there was a big effort to get rid of the BKL. First,unlocked_ioctl
was introduced. It lets each driver writer choose what lock to use instead. This can be difficult, so there was a period of transition during which old drivers still worked (usingioctl
) but new drivers could use the improved interface (unlocked_ioctl
). Eventually all drivers were converted andioctl
could be removed.compat_ioctl
is actually unrelated, even though it was added at the same time. Its purpose is to allow 32-bit userland programs to makeioctl
calls on a 64-bit kernel. The meaning of the last argument toioctl
depends on the driver, so there is no way to do a driver-independent conversion.