For Monday, June 1st 2009, I'm Jon Masters with a summary of today's LKML traffic.
In today's issue: The spirit of the GPL, hacking at mm_struct, retrying core dumps, security, and a generic hashlist implementation.
The spirit of the GPL. Luis Rodriguez asked about the recursive (or otherwise) nature of applying the EXPORT_SYMBOL_GPL macro at symbol export. He wanted to know whether it was always wrong for shims and/or wrappers to somehow cause "GPL only" symbols to be exposed to differently licensed code, and in particular whether it would be a problem to write a translation-like layer that did more than simply directly re-export a symbol. For example, he wondered aloud whether a generic bus-agnostic API layer making use of some "GPL only" exports would be an issue. Alan Cox followed up with the obvious answer that only a court of law could provide a real legal opinion, but it is likely that Luis was asking in good faith for community feeling on the matter.
Hacking at mm_struct. Andrew Morton and Linus Torvalds had a bit of a back and forth concerning various proposals to remove exe_file and other members from mm_struct. Andrew pointed out that it's fairly "arbitray" that we use the MM countainer as a central point for a number of sched objects, to which Linus retorted that it was far from arbitrary and that the reasoning lies in the fact that, from a scheduling standpoint, one of the primary performance concerns is the TLB switch. The intent is to retain a 1:1 relationship between TLB switch and MM container, which is why thinks end up largely as they are.
Retrying core dumps. Recently, there has been some discussion concerning how the kernel handles signals received by processes that are in the process of taking a core dump. A SIGIO event in particular can spoil a dump so various ideas have been posited concerning how best to handle this. Paul Smith pointed out that the existing suggestion from Andi Kleen would result in the signal mask for the task changing to a temporary value (so that the kernel knew not to disrupt an in-progress dump) before it had been written out. Paul feels that extra hacks might be the right answer in order to keep pristine cores.
Security. In one of the more amusing mock email patches of recent times, someone proporting to be "Linus Turdvals" (obviously a freshly minted gmail account, one presumes will have a limited lifespan) posted a patch to Documentation/SecurityBugs criticizing how bugs are treated, infering the existence of a secretive cabal that makes arbitrary (wrong) decisions, and suggesting that the kernel community doesn't believe in security bugs. This was interesting timing, given the thread from the weekend in which various members of the community were discussing page allocator level sanitization. Also on a security-related note, Herbert Xu ventured into the discussion of page allocator sanitization and agreed with David Miller that zeroing of freed meta-data in kernel is largely gratuitous. Dave Miller had suggested that there were performance concerns in calling kzfree arbitrarily.
Generic hashlist implementation. Frederic Weisbecker posted a set of RFC patches implementing a new generic hashlist (in the same spirit as Steven Rostedt's generic ring_buffer) for use in stat tracing. One wonders if this might actually be more generalizable, truly in the same vain as the ring_buffer code that also still lives in the trace hierarchy.
In today's announcements: The Linux Test Project announced the Linux Test Project (LTP) for May 2009. The announce mail suggests that one should (re)read the installation documentation carefully as there have been "multiple" changes to the installation procedure. Amongst the highlights are tests for 28 new system calls, cpusets testing, SELinux tests, and various fixes. You can find the LTP at http://ltp.sourceforge.net/.
The latest kernel release remains at 2.6.30-rc7, which was releaed by Linus over the US Memorial Day weekend holiday a week ago Saturday evening.
Stephen Rothwell posted a linux-next tree for June 1st. Since Friday, Stephen has re-added the kmemcheck tree (for which he posted a number of issues in separate email messages), the mtd tree lost its build failure but gained a conflict against Linus' tree, the omap tree lost its conflict, as hinted, the kmemcheck tree gained conflicts against kmemleak, x86, and trace trees, and the entire tree continues to fail to build under an allyesconfig powerpc build time configuration. The total sub-tree count has increased to 142, following the re-addition of the kmemcheck tree as aforementioned.
Finally today, Joe Perches posted a script to integrate the 'P' and 'M' lines in the "MAINTAINERS" file such that entries are formed from a single name and email combination address.
That's a summary of today's LKML traffic. For further information visit kernel.org. I'm Jon Masters.