lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 22 Feb 2008 09:12:31 +0530
From:	Ananth N Mavinakayanahalli <ananth@...ibm.com>
To:	sfr@...b.auug.org.au
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, ak@...e.de,
	arjan@...ux.intel.com, Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	sam@...nborg.org
Subject: 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@...radead.org> 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@...r.kernel.org
> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ