Andrew Morton announced Linux 2.6.12-rc5-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc5/2.6.12-rc5-mm1/
Added Oracle's clustering filesystem driver, via git-ocfs.
OCFS2, a shared disk cluster file system. See Documentation/filesystems/ocfs2.txt Additionally a users guide is available at: http://oss.oracle.com/projects/ocfs2-tools/dist/documentation/users_guide.txt
- New Xtensa architecture: Tensilica Xtensa CPU series.
- Added the Red Hat distributed lock manager for people to look at.
Various new git trees. The remaining holdouts are:
bk-acpi.patch
bk-drm.patch
bk-drm-via.patch
bk-input.patch
bk-nfs.patch
bk-watchdog.patch- The CPU scheduler is probably busted on the less-common architectures. For now, those architectures will need to emulate sched-remove-set_tsk_need_resched-from-init_idle-v2-ia64-fix.patch
- Added the s390 team's execute-in-place driver. Not sure that I like all the code duplication in this though.
- Again, if there are patches in here which you think should be merged in 2.6.12, please point them out to me.
- CPU scheduler udpates, kexec/kdump updates, i2o updates, v4l updates, etc.
Jaroslav Kysela said:
I created new git tree for the ALSA project at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/perex/alsa.git
This tree is intended for pushing ALSA changes to Linus and will follow the kernel development/release cycles once synced for the first time. It contains all latest patches from ALSA 1.0.9 now.
I will create another repository (probably alsa-devel.git) for testing the latest ALSA driver changes (suited for the -mm kernels).
Linus Torvalds pointed out that Jaroslav's conversion to git left blank lines at the start of each commit message, which interfered with some web-based git repo browsers.
There was some discussion that perhaps git should strip off extraneous whitespace, but the bottom line was that log messages could be pure binary data, and so stripping some of that off would only serve to corrupt it in those cases. In the end, Jaroslav just reconverted his tree without the extra spaces.
Jaroslav's tree had another anomaly - the "Signed-off-by" lines did not put the true author on top, as they should. At one point Linus explained:
the algorithm is:
- the email author, _or_ if there is one, the top "From:" in the body.And the rule is that you never remove (or add to) an existing From:, since the author doesn't change from being passed around.
Put another way: authorship is very different from sign-off. The sign-off gets stacked, the authorship is constant, and thus the rules are different.
Also, authorship is more important than sign-off-ship, so authorship goes at the top, while sign-offs go at the bottom.
Later, Jaroslav reconverted his tree again, to conform to this logic.
Chris Wright announced Linux 2.6.11.11, saying:
We (the -stable team) are announcing the release of the 2.6.11.11 kernel.
The diffstat and short summary of the fixes are below.
I'll also be replying to this message with a copy of the patch between 2.6.11.10 and 2.6.11.11, as it is small enough to do so.
The updated 2.6.11.y git tree can be found at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.11.y.git
and can be browsed at the normal kernel.org git web browser:
One of the fixes was for a USB oop, and the fix was attributed to Gregor
Jasny. Lee Revell pointed out that the true author was Karsten Wiese. Lee
said, Someone must have signed off on it incorrectly,
presumably the person who submitted it for -stable.
Chris confirmed,
Yes, you are right, the git commit scripts culled
that author info from the person who submitted it to -stable.
Linus
Torvalds remarked:
Side note: the patch-applicator scripts will, if the first line of the email body is of the form "^From: xxxx", and there's exactly one '@' sign on that line, then it will assume that it's supposed to be the author info, and use that instead of the "From: " line in the header of the email.
So when passing on stuff from others, that's always the preferred way to do it. A lot of people already follow this convention, and it might even be documented somewhere.
Carlos Silva said, the company that i work for
is going to buy a pair of Panda Gatedefenders 8200 that are linux based. To
start, they never told us or mention on their site (as far as i searched)
the use of linux in their product. Another thing is that they don't give
us root access nor any other type of local access to the box besides the
http page the appliance have to be managed. The thing is that i asked for
the kernel source they use in the system and they said they can't give it
since they have some proprietary code in it, as far as i understood.
Måns Rullgård said the company was not obligated to give full access
to the machine. But he did say, If
they use some modules of their own writing, the general agreement seems to
be that they don't need to release the source code to those. They should
still give you the kernel source they used, along with any patches they may
have applied.
Carlos said he was aware of these requirements, but reiterated, The thing is that they don't give me anything. They only
sell me the appliance, nothing more. :(
Måns replied, All too common. You should begin by kindly
pointing out what their obligations are, and if they fail to comply, switch
to a harsher tone, and post your correspondence in a public place. I'm not
certain that lkml is the proper place for this, but it may be the only place
we have. If all else fails, slashdot them. That will probably also fail,
but at least you can enjoy watching other people call them names.
Carlos replied, i aslready asked them in kindly
and harsher tone, so it's a dead end here.
Giuseppe Bilotta suggested going to http://www.gpl-violations.org/.
Adrian Bunk said:
gcc 4 is not supported for compiling kernel 2.4, and I don't see any compelling reason why kernel 2.4 should ever be adapted to gcc 4.
This patch documents this fact.
Mikael Pettersson pointed out that This is redundant. Any attempt to compile vanilla 2.4 with gcc4
will fail with compilation errors.
But Adrian replied:
Without this patch, your screen is flooded with warnings and errors when accidentially trying to compile kernel 2.4 with gcc 4.
With this patch, the same happens, but the last lines contain the explanation
#error Sorry, your GCC is too recent for kernel 2.4
Jeff Garzik said:
Just made a run through the libata docs, updating them for the latest hooks and filling in missing details like locking/context documentation. I've been playing with lulu.com self-publishing, and published this newly updated libata Developer's Guide there as a short book (92 pages):
http://www.lulu.com/content/130446
I think the muddy road on the front cover is apropos :)
This guide continues to be open source -- just run "make pdfdocs" in the kernel source tree.
A PDF of the book is available for free on lulu.com or at http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata.pdf or by running "make pdfdocs" (or "make psdocs", "make htmldocs", ...).
The source code for the guide is in the kernel source tree, with new additions in the 'docs' branch of
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
Marcelo Tosatti announced Linux 2.4.31-rc2, saying:
It incorporates two small hardening fixes from Willy's -hotfix tree.
v2.4.31 will follow shortly.
PS: beginning from v2.4.31 the v2.4 tree will reside in a GIT repository.
Marcelo Tosatti announced Linux 2.4.31, with no changes from 2.4.31-rc2. Presumably all development is now done in git.