[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1421627742.3787.6.camel@ellerman.id.au>
Date: Mon, 19 Jan 2015 11:35:42 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Shuah Khan <shuahkh@....samsung.com>
Cc: linux-kernel@...r.kernel.org, mmarek@...e.cz,
gregkh@...uxfoundation.org, akpm@...ux-foundation.org,
rostedt@...dmis.org, mingo@...hat.com, davem@...emloft.net,
keescook@...omium.org, tranmanphong@...il.com, cov@...eaurora.org,
dh.herrmann@...il.com, hughd@...gle.com, bobby.prani@...il.com,
serge.hallyn@...ntu.com, ebiederm@...ssion.com,
tim.bird@...ymobile.com, josh@...htriplett.org, koct9i@...il.com,
linux-kbuild@...r.kernel.org, linux-api@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH 1/6] selftests: Introduce minimal shared logic for
running tests
On Fri, 2015-01-16 at 10:53 -0700, Shuah Khan wrote:
> On 01/09/2015 02:06 AM, Michael Ellerman wrote:
> > This adds a Make include file which most selftests can then include to
> > get the run_tests logic.
> >
> > On its own this has the advantage of some reduction in repetition, and
> > also means the pass/fail message is defined in fewer places.
> >
> > However the key advantage is it will allow us to implement install very
> > simply in a subsequent patch.
> >
> > The default implementation just executes each program in $(TEST_PROGS).
> >
> > We use a variable to hold the default implementation of $(RUN_TESTS)
> > because that gives us a clean way to override it if necessary, ie. using
> > override. The mount, memory-hotplug and mqueue tests use that to provide
> > a different implementation.
> >
> > Tests are not run via /bin/bash, so if they are scripts they must be
> > executable, we add u+x to several.
> >
> > Signed-off-by: Michael Ellerman <mpe@...erman.id.au>
>
> I like the shared logic approach in general provided it leaves the
> flexibility to not use the shared logic if a test have the need to
> do so.
Yes of course it does, it's entirely optional to include lib.mk.
> This series requires some patch planning. shared logic patch
> followed by individual test patches as opposed a single patch.
It could be a single patch too, but there's no reason to do it that way. The
series works fine as I sent it.
> I would like to see the shared logic work done on top of my patch v4
> series.
That's a waste of time. This series replaces your v4. Doing this "on top" of
your v4 would just mean reverting your v4 series and then applying this.
cheers
--
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