[lkml]   [2012]   [Feb]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/3] move hugepage test examples to tools/testing/selftests/vm
    On 02/07/2012 07:53 AM, Andrew Morton wrote:

    > On Sun, 5 Feb 2012 16:15:55 +0800
    > Dave Young <> wrote:
    >> hugepage-mmap.c, hugepage-shm.c and map_hugetlb.c in Documentation/vm are
    >> simple pass/fail tests, It's better to promote them to tools/testing/selftests
    >> Thanks suggestion of Andrew Morton about this. They all need firstly setting up
    >> proper nr_hugepages and hugepage-mmap need to mount hugetlbfs. So I add a shell
    >> script run_test to do such work which will call the three test programs and
    >> check the return value of them.
    >> Changes to original code including below:
    >> a. add run_test script
    >> b. return error when read_bytes mismatch with writed bytes.
    >> c. coding style fixes: do not use assignment in if condition
    > I think Frederic is doing away with tools/testing/selftests/run_tests
    > in favour of a Makefile target? ("make run_tests", for example).


    > Until we see such a patch we cannot finalise your patch and if I apply
    > your patch, his patch will need more work. Not that this is rocket
    > science ;)


    >> ...
    >> --- /dev/null
    >> +++ b/tools/testing/selftests/vm/run_test
    > (We now have a "run_tests" and a "run_test". The difference in naming
    > is irritating)

    Yes, I'm just refer to the breakpoints/Makefile which will make a target

    > Your vm/run_test file does quite a lot of work and we couldn't sensibly
    > move all its functionality into Makefile, I expect.
    > So I think it's OK to retain a script for this, but I do think that we
    > should think up a standardized way of invoking it from vm/Makefile, so
    > the top-level Makefile in tools/testing/selftests can simply do "cd
    > vm;make run_test", where the run_test target exists in all
    > subdirectories. The vm/Makefile run_test target can then call out to
    > the script.

    Frederic, do you have any idea about this?

    > Also, please do not assume that the script has the x bit set. The x
    > bit easily gets lost on kernel scripts (patch(1) can lose it) so it is
    > safer to invoke the script via "/bin/sh script-name" or $SHELL or
    > whatever.

    Agree, and quilt can not keep the x bit as well, I have to use git to
    create a executable shell script

    > Anyway, we should work with Frederic on sorting out some standard
    > behavior before we can finalize this work, please.

    Fine, I can redo this after the standard behavior is out


     \ /
      Last update: 2012-02-07 02:31    [W:0.047 / U:12.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site