From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752724AbaKLBHW (ORCPT ); Tue, 11 Nov 2014 20:07:22 -0500 Received: from lists.s-osg.org ([54.187.51.154]:44427 "EHLO lists.s-osg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752105AbaKLBHP (ORCPT ); Tue, 11 Nov 2014 20:07:15 -0500 Message-ID: <5462B2A3.9000007@osg.samsung.com> Date: Tue, 11 Nov 2014 18:06:43 -0700 From: Shuah Khan Organization: Samsung Open Source Group User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Kees Cook CC: Greg KH , Andrew Morton , Michal Marek , "David S. Miller" , Phong Tran , David Herrmann , Hugh Dickins , pranith kumar , "Eric W. Biederman" , "Serge E. Hallyn" , linux-kbuild , LKML , Linux API , Network Development Subject: Re: [PATCH v2 07/19] selftests/firmware: add install target to enable installing test References: <1d2d13556ddbbbbb13989cdcb08447909bc4afaf.1415735831.git.shuahkh@osg.samsung.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/11/2014 02:29 PM, Kees Cook wrote: > Hi, > > Sorry, I still really don't like this approach. While it is all in one > place (thank you for that), I think it isn't a form that is very > workable for the people maintaining the self tests. How about this, > instead of per-Makefile customization, why not define an execution > framework for these tests instead. If I understand correctly, sounds like you don't like the way install target is implemented in the individual test Makefiles and the changes I made to run_tests targets to address the code duplication concern. At the moment there is no duplicate code in this patch series between install and run_tests targets. This is a first step towards standardizing the framework and a definite improvement over what we have currently. As I mentioned earlier, my goal is to make it easier for developers to install and run the existing tests and evolve the framework as we go. Assuming my understanding is correct that: -- install and run_tests targets in individual tests can be refined and automated with a common Makefile approach you proposed. -- the rest of the user-interface kselftest_install and kselftest are good. I would like to propose that we get started with the current implementation and refine it based on the following ideas you suggested. The refinements you are recommending are confined to selftests and can be made after the kselftest_install gets added. Adding kselftest_install makes it easier to make the refinements as it defines overall UI. > > For example, how about every test directory must have a Makefile with > the needed binary targets. A common makefile could be included that > defines the "run_tests" target that calls the script "run_tests.sh" > that is a shell script in the current directory. (For inspiration, see > how kernel modules can be built out of tree.) > > The "run_tests.sh" scripts could all include a common shell script, > say "../common.sh" that provides any common variables, functions, etc > (e.g. things like "Start $name test ..." should be in common.sh > instead of repeated in every script, the installation logic can be in > once place instead of repeated). > > Then along side common.sh could be "run_installed_tests.sh" or > something, used on the installed target, that would traverse each > directory, etc. From this, we can have a much more data-driven > framework, and a common approach to running tests. > > As such, we should declare up front how tests should behave on > failure. And the top-level test runner can do things like count the > number of tests, failures, etc. > > Then, instead of splitting up the patches by test directory, you can > split them up by logical changes (e.g. defining the common "run_tests" > target, and then removing the target from all the tests by including > the common makefile stub that defines it). > These are good ideas and I am with on evolving the framework to make it easier to maintain individual tests. Patches are welcome. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Samsung Research America (Silicon Valley) shuahkh@osg.samsung.com | (970) 217-8978