For Wed, June 3rd, 2009, I'm Jon Masters with a summary of today's LKML traffic.

In today's issue: Xen, zero page pointers, detailed stack information, 
filesystem notification of errors, printk halt delay, and hardware
breakpoints.

Xen. As if there would be any other top discussion item today. Discussion
continues on the topic of the potential for a future merge of the Xen Dom0
hypervisor support into the official Linux kernel. Following various comments
yesterday, Steven Rostedt landed this bombshell suggestion: "Now here's a crazy
solution. Merge the Xen hypervisor into Linux". Reaction was typically
unexpected with both Ingo Molnar and Thomas Gleixner coming out in favor of
the idea of simplifying the hypervisor in merging it with the core kernel. But
Xen is more than just a hypervisor for Linux and the idea of it ever being
merged into the Linux kernel seems more than far fetched. Ingo's suggestion
that much of the paravirt code could go given modern CPU support for hardware
virtualization sounded particularly optimistic and unlikely. Joel Becker gave
a nice concrete example of hardware at his disposal that is big and meaty,
only a couple of years old, and does not support hardware virtualization.

Perhaps most interesting, was a reply to Ingo from Rusty Russell (replying to
the notion that enabling CONFIG_PARAVIRT can have a small negative impact upon
those who don't use it), in which Rusty put forward various figures showing the
relative impacts of various configuration options on the kernel, and putting in
context how little a small overhead for virtualization really is, in comparison
to other config options one might enable in the kernel. Rusty's figures showed
an average 15% slowdown, worst case of 69% and best case of 2% speedup depending
upon which of a few sets of different kernel configuration options he enabled.
Linux Weekly News has a subscriber-only story covering the Xen situation with
a lot more detail, and subscribers are encouraged to take a look at that.

Zero page pointers. Typically, the NULL (zero) page is never directly mapped
by application code, and attempting to use it results in the well-known NULL
pointer exception (because the address is not mapped). However, there are some
occasional uses for NULL page mappings - chiefly vm86, wine, and some legacy C
compilers - and so the kernel doesn't ban it outright. Instead, it makes being
able to map the NULL page a CONFIG_SECURITY dependent option. Depending upon
SELinux policy, the value of SECURITY_DEFAULT_MMAP_MIN_ADDR, and the setting
of /proc/sys/vm/mmap_min_addr, an application may be able to map that page.
Various discussion around this took place, including whether the default
should depend upon SELinux being enabled and whether distributions were doing
the right thing - Linus pointed out that he turns off SELinux and knows "lots
of other sane people do too. So the !SElinux case really does need to work".

Detailed stack information. Stefani Seibold posted a patch allowing detailed
task stack information to be fully exposed to userspace. As Stefani noted,
"currently you are only able to dump the main process/thread stack usage which
is showed in /proc/pid/status by the "VmStk" value. But you get no information
about the consumed stack memory [of] the threads". The patch implements a
/proc/pid/task/*/maps hierarchy enhancement.

Filesystem notification of errors. Denis Karpov posted a patch series
implementating a new kernel<->userspace interface via sysfs (and accompanying
uevent emmision to which udev - or another multiplexed netlink receiver - can
take appropriate action) that provides notification upon certain filesystem
errors. Previously, many kernel filesystems would "remount" themsevles
read-only under such unfortunate circumstances, but the response was never
entirely clean and it was hard for userspace to take appropriate recovery
action other than having one service after another fail. Now, userspace can
monitor for such errors and take action - simply by passing the new "notify"
mount time option.

Printk halt delay. Dave Young posted a patch implementing a halt delay feature
for printk, very similar to the init or boot delay that already exists. The
idea is that there are some systems where you cannot easily capture all of the
kernel output as it goes down for halt other than by physically watching the
output device as messages scroll on the screen or similar device. The patch
adds a new "halt_delay" parameter to printk, accessible using the
/sys/module/printk filesystem hierarchy, implementing the obvious.

Hardware Breakpoint API. Frederic Weisbecker reposted his Hardware Breakpoint
API, saying it has "benefit from deep reviews since its first iteration
several months ago, and Prasad has address most (all?) of them). After a small
reorg and a few fixes that were done recently, it seems ready for integration
on -tip". It seems likely that this will be merged into 2.6.31.

Finally today. Andrew Morton followed up to the previous thread on Floppy Disk
Hibernation with the following changelog entry: "This fix resets the floppy
controller on resume. It was experimentally determined to bring the controller
back to life - we don't really know why it works.". Having previously asked
for someone to "save us" from the floppy code, it seems as if Andrew will have
to wait a while before true salvation will come.

In today's announcements: No major announcements today.

The latest kernel release is 2.6.30-rc8, which was released by Linus shortly
after 9pm PDT on Tuesday evening. He mentions that he had debated doing an rc8
but in the end came to the conclusion to push one before 2.6.30 final. Quoting
Linus, "the small stuff does matter. Please test.".

Andrew Morton published an mm-of-the-moment for 2009-06-02-16-11.

Stephen Rothwell posted a linux-next tree for June 3rd. In his words, "Looks
like a real rush since -rc7". That, really, is putting it mildly. Since
Tuesday, the device-mapper tree was moved (since it assumes various commits in
the block tree have been applied), the x86 tree lost its conflict, the kvm
tree gained a conflict against the x86 tree, the net tree gained a conflict
against Linus' tree, the wireless tree gained conflicts against the x86 and
acpi trees, and a build failure for which Stephen reverted 2 commits from the
acpi tree. The block tree lost its build failure due to updates to the
device-mapper tree, the genirq tree lost its 2 conflicts, the trivial tree
gained a conflict against the wireless tree, the driver-core tree gained
conflicts against the trivial, x86, firmware and ttydev trees, and the ubi
tree gained a build failure for which Stephen reverted 2 commits. The total
sub-tree count remained steady at 142 trees for Wednesday's tree compose.

Finally today. This podcast has been going for a month now. Over the past few
weeks, there have been around 17,000 downloads at an average of 300 listeners
per day (more on weekends). These are encouraging, and the exercise helps your
author keep up with LKML, and so it will continue. Since this is a spare time
activitiy, one cannot promise to keep to any regular schedule, although I can
say that it is my intention to cover every single day of LKML traffic. I also
will experiment with music, formatting, and producing a lengthier show on
weekends with a full 15-30 minute summary of the week's events. I am
interested in advice, especially on recording and production - I'm sure there
are better microphones and processes I can build around my use of audacity so
that the listener experience is cleaner, crisper, and more enjoyable. If you
have advice, comments, or other helpful feedback, please do email me. If you
work on the kernel and would like to record a 30 second summary of your work,
drop me a line also - I'd love to splice in a few of these between segments.

That's a summary of today's LKML traffic. For further information visit kernel.o
rg. I'm Jon Masters.