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.