Replace GPL license statement with SPDX GPL-2.0 license identifier.
Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com>
---
tools/testing/selftests/gen_kselftest_tar.sh | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/tools/testing/selftests/gen_kselftest_tar.sh b/tools/testing/selftests/gen_kselftest_tar.sh
index 17d5bd0c0936..a27e2eec3586 100755
--- a/tools/testing/selftests/gen_kselftest_tar.sh
+++ b/tools/testing/selftests/gen_kselftest_tar.sh
@@ -1,13 +1,11 @@
#!/bin/bash
#
+# SPDX-License-Identifier: GPL-2.0
# gen_kselftest_tar
# Generate kselftest tarball
# Author: Shuah Khan <shuahkh(a)osg.samsung.com>
# Copyright (C) 2015 Samsung Electronics Co., Ltd.
-# This software may be freely redistributed under the terms of the GNU
-# General Public License (GPLv2).
-
# main
main()
{
--
2.14.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
Android kernel team is planning to develop procfs and sysfs tests and
contribute them to linux-kselftest project. The plan for sysfs tests right now,
as suggested by Greg KH, is to write a minimal "generic" test framework
that allows you to easily specify:
- file location
- expected value type (integer, string, range of values, etc.)
- expected permissions
Could/should this approach be extended to test procfs and other virtual
filesystems? We would really appreciate some input on the test plan. :)
Thanks,
Tri Vo
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/06/2017 12:57 AM, Ram Pai wrote:
> Expose useful information for programs using memory protection keys.
> Provide implementation for powerpc and x86.
>
> On a powerpc system with pkeys support, here is what is shown:
>
> $ head /sys/kernel/mm/protection_keys/*
> ==> /sys/kernel/mm/protection_keys/disable_access_supported <==
> true
This is cute, but I don't think it should be part of the ABI. Put it in
debugfs if you want it for cute tests. The stuff that this tells you
can and should come from pkey_alloc() for the ABI.
http://man7.org/linux/man-pages/man7/pkeys.7.html
> Any application wanting to use protection keys needs to be able to
> function without them. They might be unavailable because the
> hardware that the application runs on does not support them, the
> kernel code does not contain support, the kernel support has been
> disabled, or because the keys have all been allocated, perhaps by a
> library the application is using. It is recommended that
> applications wanting to use protection keys should simply call
> pkey_alloc(2) and test whether the call succeeds, instead of
> attempting to detect support for the feature in any other way.
Do you really not have standard way on ppc to say whether hardware
features are supported by the kernel? For instance, how do you know if
a given set of registers are known to and are being context-switched by
the kernel?
--
To unsubscribe from this list: send the line "unsubscribe linux-kselftest" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html