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:	Thu, 12 Mar 2015 14:11:53 +1100
From:	Michael Ellerman <mpe@...erman.id.au>
To:	Shuah Khan <shuahkh@....samsung.com>
Cc:	linux-kernel@...r.kernel.org, davej@...emonkey.org.uk,
	mmarek@...e.cz, linux-api@...r.kernel.org
Subject: Re: [PATCH v4 4/9] selftests: Add install target

On Wed, 2015-03-11 at 10:03 -0600, Shuah Khan wrote:
> On 03/11/2015 07:18 AM, Shuah Khan wrote:
> > 
> > I don't see my comments addressed. If you want me to take
> > this work, please address the following comments:
> > 
> > - Name install directory kselftest. It should work with the
> >   the use-case.
> > 
> >   make INSTALL_PATH=/tmp make install
> >   The install directory should be /tmp/kselftest
> > 
> > - Flatten the directory with all tests under /tmp/kselftest
> > 
> 
> Yes. There is the issue of duplicate executable names and data
> file to be concerned about. It is a name-space problem. It is
> not unique to this case, example /usr/bin. This problem is better
> solved without adding the complexity of hierarchical directory
> structure.
> 
> 1. Individual test Makefiles ensure unique names for their
>    executables and data files. This can be done as a process
>    when new tests are accepted.
> 2. Install process makes sure they are unique - this patch is
>    solving the problem by creating a directory hierarchy. A simpler
>    way to do it is by adding pre-fix to when there is name space
>    conflict.
> 
> The problem with directory hierarchy is for one thing:
> 
> 1. It is complex and way too many directories get created during
>    install and this problem will mushroom as more and more tests
>    get added.

One directory is created for each test directory under selftests. That's not
"way too many" directories.

Why does it make sense to have directories for the selftest sources, but not
the installed tests? Why don't we just put all the tests in one directory under
selftests? A: Because that would be stupid.

$ find tools/testing/selftests/ -maxdepth 1 -type d
tools/testing/selftests/
tools/testing/selftests/size
tools/testing/selftests/memory-hotplug
tools/testing/selftests/ipc
tools/testing/selftests/ptrace
tools/testing/selftests/timers
tools/testing/selftests/efivarfs
tools/testing/selftests/net
tools/testing/selftests/kcmp
tools/testing/selftests/mqueue
tools/testing/selftests/ftrace
tools/testing/selftests/mount
tools/testing/selftests/vm
tools/testing/selftests/firmware
tools/testing/selftests/cpu-hotplug
tools/testing/selftests/user
tools/testing/selftests/sysctl
tools/testing/selftests/powerpc
tools/testing/selftests/exec
tools/testing/selftests/memfd
tools/testing/selftests/breakpoints
tools/testing/selftests/rcutorture

Oh no directories, they're so complex!

> 2. User won't be able to define a simple path variable to invoke
>    individual tests. This is a user experience problem.

Who cares? No one does that. Many of the tests aren't just simple executables
that can be run via $PATH, they require test files in the current directory.

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