KernelTrap - Adrian Bunk

Quote: Kernel Development Is Driven By Patches

Jeremy — Tue, 22 Jan 2008 17:39:37 +0000

"Linux kernel development is not driven by people producing hot air about what they wish to see in the future, Linux kernel development is driven by people sending patches."

Quote: Easter Bunny

Jeremy — Tue, 15 Jan 2008 03:14:28 +0000

"I don't think anything of what was discussed in this thread would be in scope for 2.6.24 (unless Linus wants to let the bunny that brings eggs release 2.6.24)."

Modular IO Schedulers

Jeremy — Mon, 26 Nov 2007 21:23:24 +0000

Adrian Bunk posted a patch to make Linux IO schedulers a non-modular option, which would require one IO scheduler to be selected at compile time. He suggested, "there isn't any big advantage and doesn't seem to be much usage of modular schedulers." He added that removing the option to make IO schedulers modular would save 2kB on each kernel image. Jens Axboe did not like the patch, "big nack, I use it all the time for testing. Just because you don't happen to use it is not a reason to remove it." When Adrian noted that no distros seemed to be making IO schedulers available as modules, Jens suggested that this was a mistake and quipped, "it's been a long time since I considered a distro .config a benchmark/guideline of any sort."

Adrian went on to ask for the technical reasons for continuing to support four different IO schedulers, expressing concern that it could lead to bugs in individual schedulers going unreported. Jens explained that he was aiming for the perfect IO scheduler, but at this time different IO schedulers offer better results for different workloads, "with some hard work and testing, we should be able to get rid of [the anticipatory scheduler]. It still beats cfq for some of the workloads that deadline is good at, so not quite yet." Arjan van de Ven offered, "there is at least one technical reason to need more than one: certain types of storage (both big EMC boxes as well as solid state disks) don't behave like disks and have no seek penalty; any cpu time spent on avoiding seeks is wasted on those, so for these devices one really wants to use a different IO scheduler, one which is much lighter weight". Jens then acknowledged, "there's always a risk with 'duplication', like several drivers for the same hardware. I'm not disputing that."

Stable 2.6 Branches

Jeremy — Fri, 09 Nov 2007 19:15:43 +0000

"For the last release, I stated that I thought the 2.6.22.12 release would be the last one in the 2.6.22.y series. Since then, I've received a number of other patches that would be nice to have in the .22.y tree," explained Greg KH. He continued:

"So, for a while, I'll keep the 2.6.22.y tree open, doing new releases every once in a while as they accumulate. I do this, for no other than the selfish reason that I use it every day on my openSuSE 10.3 boxes as that is the kernel base that release is on :)"

Greg KH and Chris Wright have been maintaining a -stable 2.6.x.y patchset for the 2.6.x and 2.6.(x-1) kernels since March of 2005. 2.4 stable kernel maintainer Willy Tarreau has also maintained patches against the 2.6.20 branch since August of 2007, though noted that he'll switch to maintaining the stable 2.6.22 branch once Greg finishes. Adrian Bunk also continues to maintain a -stable 2.6.16 branch of the Linux kernel.

The GPL and Embedded Applications

Jeremy — Fri, 12 Oct 2007 00:15:28 +0000

"There are no 'persons responsible for defending the kernel GPL', there are just a few hundreds or thousands copyright holders of the kernel, and each of them has the right to sue you if he thinks you distribute something that violates his copyright," Adrian Bunk responded in a recent discussion about the legality of linking to GPL'd code in embedded applications. He added, "jurisdiction and applicable copyright law depends on things like where the copyright holder lives and where you distribute it." When it was asked how the constraints of a given piece of hardware might affect the interpretation of the GPL, Theodore T'so explained:

"At the end of the day it all boils down to what is a derived work. If an object file which is designed to link into a kernel is a derived work, then the GPL claims that it will infect across to that derived work. Whether or not it this is a case is a matter of much debate, and as far as I know, no court has ever ruled on point regarding the question of object files, dynamical linking, and whether or not that would be a derived work or not. It seems likely that the answer may vary from one legal jurisdiction to another. Hence, the only answer that we can give which is useful is, 'Take this off of LKML, and go ask a lawyer.'"

Abusing chroot

Jeremy — Thu, 27 Sep 2007 06:35:39 +0000

"If you have the ability to use chroot() you are root. If you are root you can walk happily out of any chroot by a thousand other means," Alan Cox explained during a thread that suggested chroot was broken in Linux. It was further pointed out that this was true per the POSIX specification, and per other OS's implementations. Al Viro suggested this should be added to the lkml FAQ, explaining:

"If you are within chroot jail and capable of chroot(), you can chdir to its root, then chroot() to subdirectory and you've got cwd outside of your new root. After that you can chdir all way out to original root. Again, this is standard behaviour. Changing it will not yield any security improvements, so kindly give that a rest."

When it was suggested that chroot is frequently used as a security tool, Adrian Bunk retorted, "incompetent people implementing security solutions are a real problem." Alan added, "chroot is not and never has been a security tool. People have built things based upon the properties of chroot but extended (BSD jails, Linux vserver) but they are quite different."

Linux: Supporting Older GCC Releases

Jeremy — Wed, 22 Aug 2007 06:03:24 +0000

A recent bug report led to a discussion about potentially dropping support for pre-4.0 versions of GCC. Adrian Bunk noted, "currently we support 6 different stable gcc release series, and it might be the right time to consider dropping support for the older ones. Are there any architectures still requiring a gcc < 4.0 ?" Russell King noted that on some architectures GCC 3.x is still preferable to the newer 4.x branch, "I want to keep support for gcc 3.4.3 for ARM for the foreseeable future. From my point of view, gcc 4 compilers have been something of a development thing as far as the ARM architecture goes. Also, gcc 3.4.3 is faster and significantly less noisy than gcc 4."

When it was asked how many kernel developers use older version of GCC, Linus Torvalds explained that it really doesn't matter, "it's NOT about 'kernel developers'. It's about random people testing kernels. If we make it harder for people to test kernels, we're going to lose. So no, I vote for *not* cutting off old gcc versions unless it's absolutely fatal."

Linux: Determining Maintainers

Jeremy — Tue, 14 Aug 2007 17:25:34 +0000

In an overwhelmingly large series of 556 patches, Joe Perches attempted to track down maintainers for a significant number of files within the Linux kernel source tree. He explained, "I grew weary of looking up the appropriate maintainer email address(es) to CC: for a patch", adding a new line format to the kernel MAINTAINERS file parsed by a new get_maintainer.pl script.

Much of the feedback was criticism of the large number of patches that flooded the inboxes of all subscribers to the Linux Kernel Mailing List. Others suggested that the information would be better extracted from Git than from source files. When Joe asked for better ideas for achieving his end goal, Alan Cox suggested, "working off the git tree as it shows who actually is making changes/updating stuff recently and why which is a major clue when tracing bugs". Chris Wright pointed out, "I think this data will easily become stale. What is the point again?" going on to add "between git (or gitweb), existing MAINTAINERS and a bit of common sense (or extra sleuthing), I never perceived a significant problem." Adrian Bunk countered, "for active kernel developers like you and me it's not a problem. But for other people it's non-trivial to always figure out who the maintainer of some part of the kernel is."