* Andrew Morton <akpm@linux-foundation.org> wrote:
all of these are in linux-next, and most of them are in -mm.
the for-akpm branch has 646 commits at the moment (these are the ones
that are in -mm), out of 890 patches. These are the "pure arch/x86"
topic patches, and which will be offered in the first wave of pull
requests.
Of the remaining patches, they'll be offered under different topics, in
different temporary branches (or trees) depending on which subsystem
they interact with. There will be no "take it or leave it" big pull
request.
Some patches are later in the queue because they depend on generic
infrastructure.
Some wont be offered for a pull at all because they belong into other
subsystems and we just track them via x86.git because it's some
important topic or dangerous-looking patch we'd like to see the effects
of first-hand.
[ sorry about not having described this in detail in my mail - i spent
the last 3 work days on a 2.6.25 regression almost non-stop, so x86
queue cleanup lagged behind a bit and my description of the changes
was rather terse. ]
none.
but we do much more testing than just getting code into other trees. We
cross-build 96 different configurations on other non-x86 architectures:
http://www.tglx.de/autoqa-cgi/index?run=81&tree=1
last night's run was: 96 out of 96 configs built successfully.
This covers: alpha, arm, mips, powerpc, sparc64, x86, m32r, powerpc,
xtensa, mips, sh, sparc, parisc, powerpc. We test the various branches
(amongst them for-akpm) and combination trees as well.
and the backbone of arch/x86 QA we do are the build, boot and stress
tests we do on x86: we ran and booted thousands of x86 randconfigs in
the past few days alone. x86/latest boots and works from the smallest
boxes up to a 64-way testbox. On the 64-way box i did a 1 week burn-in
stress-test last week as well, for any longer-term effects.
you mean the original hack? Sure, that had a number of problems and we
are not offering that for a merge.
But have you seen the latest code we are offering for merge? Check out
sched-devel/latest and kernel/trace/trace_sysprof.c. Nicely generalized
on top of stacktrace.h, put into the ftrace framework, userspace has
been ported to that too. No more special sysprof-only API hack.
ok, will fix.
... that defeats one of the security purposes of this feature. (which is
to make it a bit harder for rootkits to just patch themselves in via
/dev/mem)
thanks, fixed. This patch will be backmerged shortly before pushout
anyway (like you do for -mm, to maintain bisectability) so the title
does not matter (the fix and credit will be added to the original
patch).
Note that this is from the tail of the queue - not all commit entries
are sanitized yet.
no.
I think what caused the confusion is that the cleaned up sysprof ftrace
plugin depends on the presence of the ftrace infrastructure, which is in
sched-devel. The patch you see in x86.git is the (now obsolete, and
removed) sysprof code. Those interim commits show up in the shortlog but
we (of course) wont push them upstream. Sorry about the confusion ...
i just cleaned this up and pushed out a new x86.git and sched.git.
Ingo
--
