Re: [GIT PULL?] Create and populate toplevel tests/ for kernel tests

On Tue, Feb 19, 2008 at 08:21:53PM +0100, Sam Ravnborg wrote:
Hi Anath.

Linus did not pull this in the -rc1 to -rc2 timeframe
so please resubmit the patch serie one week into the
next merge window (when most of the trees has hit linus' tree
and Andrew has made his first merge).

IF you need an extra eye balling then you can submit
a few weeks before the merge window opens.
Thats typical after an -rc with only a few patches.

Stephen,

The patchset in question is just a major code movement - basically to
move all in-kernel tests to live under a toplevel tests/ directory. As
such, all the stakeholders have acked the patchset, but it does look
like this is a big enough change to be deferred to the next merge
window.

Given that there is general agreement about the patchset, could you
please pull in the changes into the linux-next tree?

Sam has setup a git tree for this and you can pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/tests.git

Link to the thread: http://lkml.org/lkml/2008/2/11/97

Thanks,
Ananth

Thanks,
Sam

On Tue, Feb 12, 2008 at 11:39:18PM +0100, Sam Ravnborg wrote:
Hi Linus.

Will you consider such a primary code-movement for -rc1
or shall we wait until next merge window?

Had we hit -rc2 I would not have sent this pull req and
feel free to flame me anyway.

The rationale to get it merged is obviously to avoid
merge conflicts and the only reason I ask is that I consider
it a low risk patch.

I have not included 8/8 since it was questioned and it
will wait until next merge window. But the first 7 was
straightforward.

You can pull from:
ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/tests.git

diffstat and shortlog below.
I also included mail last with a few of the merge related comments.

Sam

Makefile | 1 +
drivers/misc/Makefile | 1 -
kernel/Makefile | 4 -
lib/Kconfig.debug | 71 +--------------------
lib/Makefile | 1 -
tests/Kconfig | 79 +++++++++++++++++++++++
tests/Makefile | 10 +++
{kernel => tests}/backtracetest.c | 0
{drivers/misc => tests}/lkdtm.c | 12 ++--
{lib => tests}/locking-selftest-hardirq.h | 0
{lib => tests}/locking-selftest-mutex.h | 0
{lib => tests}/locking-selftest-rlock-hardirq.h | 0
{lib => tests}/locking-selftest-rlock-softirq.h | 0
{lib => tests}/locking-selftest-rlock.h | 0
{lib => tests}/locking-selftest-rsem.h | 0
{lib => tests}/locking-selftest-softirq.h | 0
{lib => tests}/locking-selftest-spin-hardirq.h | 0
{lib => tests}/locking-selftest-spin-softirq.h | 0
{lib => tests}/locking-selftest-spin.h | 0
{lib => tests}/locking-selftest-wlock-hardirq.h | 0
{lib => tests}/locking-selftest-wlock-softirq.h | 0
{lib => tests}/locking-selftest-wlock.h | 0
{lib => tests}/locking-selftest-wsem.h | 0
{lib => tests}/locking-selftest.c | 0
{kernel => tests}/rcutorture.c | 0
{kernel => tests}/rtmutex-tester.c | 2 +-
{kernel => tests}/test_kprobes.c | 0
27 files changed, 99 insertions(+), 82 deletions(-)

Ananth N Mavinakayanahalli (7):
Create tests/ directory
Move locking selftests to tests/
Move rcutorture to tests/
Move rtmutex-tests to tests/
Move lkdtm to tests/
Move kprobes smoke tests to tests/
Move backtrace tests to tests/



On Tue, Feb 12, 2008 at 01:22:46PM -0800, Andrew Morton wrote:
On Tue, 12 Feb 2008 11:44:52 -0500
Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

On Mon, Feb 11, 2008 at 04:14:52PM +0530, Ananth N Mavinakayanahalli wrote:
The following series of patches create and populate the toplevel tests/
directory. This will henceforth be the place where all in-kernel tests
live.

All patches against 2.6.25-rc1 and are just code movement without any
change in functionality.

ACK to patches 1-7, and I agree with Ingo that the x86-specific test
should stay under arch/x86.

OK. But now is basically the worst time for me (or anyone else) to merge
large code-motion changes like this, because they need to be carried for
two months or more.

And even though git can track renames, putting them into a git tree (say,
git-kbuild) won't help, because if some other git tree tries to modify a
file in its original place, I get to fix up the fallout.

Which I _could_ do, and would do if the patches were particularly risky or
added/changed functionality or whatever. But they don't do that, and there
is little advantage in maintaining them for the >2 months.

So. Please redo and resend the patches when we hit 2.6.25-rc6 or so?

Thanks.

(linux-next will largely fix all this: git will take care of the renames
and I'll just base the -mm queue on the consolidated linux-next. But we
aren't there yet).

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages