• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..--

include/23-Nov-2023-768342

tools/23-Nov-2023-2,4391,903

AOSP_license_text.txtD22-Nov-2023506 1312

Android.ltp.mkD23-Nov-2023133.9 KiB3,4402,568

Android.mkD22-Nov-20231.1 KiB3818

Android.prebuilt.mkD22-Nov-20231,009 3214

README.mdD23-Nov-20239.6 KiB216161

how-to-update.txtD23-Nov-2023467 1914

ltp_package_list.mkD23-Nov-202363.4 KiB2,3972,382

skipped-tests.txtD22-Nov-2023604 96

README.md

1VTS LTP Workflow
2================
3
4A Guide to Developing LTP for VTS/Android
5
6What is LTP?
7------------
8
9[Github](https://github.com/linux-test-project/ltp) (upstream)
10
11LTP (Linux Test Project) is a suite of tests that covers both kernel interfaces
12and userspace functionality (glibc, commonly used binaries, etc).  For the
13purposes of Android the userspace functionality testing is of less importance
14and in fact much of it must be disabled, given the functionality is not
15available in Android.
16
17As of mid-2018 there are on the order of 900 tests executed in VTS. Most tests
18are run in both 32-bit and 64-bit mode. Many more are available but currently
19disabled due to either being broken or not applicable on Android.
20
21How is LTP Run in VTS?
22----------------------
23
24The LTP source is located at external/ltp in the Android tree. This is not an
25exact mirror of upstream, there are outstanding changes to LTP for it to work
26on Android which have not yet been pushed upstream. In addition to the LTP
27source there is also the VTS wrapper around it. This is located at
28test/vts-testcase/kernel/ltp. Some noteworthy directories/files:
29
30* `external/ltp/android/`: Contains Android-specific files, aside from Android.[bp, mk] at top level.
31* `external/ltp/android/Android.ltp.mk`: Lists build rules for the LTP modules built under make. This file gets auto-generated by android/tools/gen_android_build.sh.
32* `external/ltp/gen.bp`: Lists build rules for the LTP modules built under Soong. This file gets auto-generated by android/tools/gen_android_build.sh.
33* `external/ltp/android/ltp_package_list.mk`: Lists all tests that will get pulled into VTS - VTS depends on this list. This file gets auto-generated by android/tools/gen_android_build.sh.
34* `external/ltp/android/tools/disabled_tests.txt`: Lists tests which cannot or should not be compiled for Android. This file is read by gen_android_build.sh during LTP upgrades to produce *.mk files required to build LTP for Android.
35* `external/ltp/testcases`: Source for LTP tests. Among the most important for the purposes of Treble are those in external/ltp/testcases/kernel/syscalls.
36* `test/vts-testcase/kernel/ltp/configs/disabled_tests.py`: Any test listed here will not be run in VTS, either in the staging or stable set, despite being compiled. If a test does not appear here then it at least runs as part of the VtsKernelLtpStaging module.
37* `test/vts-testcase/kernel/ltp/configs/stable_tests.py`: Any test listed here will run as part of the VtsKernelLtp (stable) module.
38
39New tests are run in the staging set for some time (a couple weeks or more) to
40ensure they are reliable prior to their being added to the stable set.
41
42To run VTS LTP it must first be built. VTS is not device specific, you need not
43compile it specifically for the device you wish to run it on, assuming it is
44the same architecture.
45
46* `. build/envsetup.sh`
47* `lunch`
48* `make -j vts`
49
50Before running VTS ensure your host has the required prerequisites (this need
51only be done once):
52* `. test/vts/script/setup.sh`
53
54Then open vts-tradefed and run the VTS stable set:
55* `vts-tradefed`
56* `vts-tf > run vts-kernel -m VtsKernelLtp`
57
58If you regularly work with multiple devices it may be useful to specify the
59specific device you wish to run VTS on via the serial number:
60* `vts-tf > run vts-kernel -m VtsKernelLtp -s 000123456789`
61
62Or we can run the staging set:
63* `vts-tf > run vts-kernel -m VtsKernelLtpStaging`
64
65Or a specific test within the stable set:
66* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13`
67
68Maybe several:
69* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13,fs.stream04`
70
71You may choose whether to specify bitness of the tests. This would run 4 tests - dio.dio13
72both 32-bit and 64-bit, fs.stream04 64-bit, and fs.lftest01 32-bit:
73* `vts-tf > run vts-kernel -m VtsKernelLtp -t dio.dio13,fs.stream04_64bit,fs.lftest01_32bit`
74
75Running LTP Faster
76------------------
77
78Running LTP tests within VTS can be quite cumbersome, especially if you are
79iterating a lot trying to debug something. Build and run LTP tests faster by
80doing
81
82* `external/ltp$ mma`
83* `external/ltp$ adb sync data`
84
85The test cases will be located at /data/nativetest{64,}/ltp/testcases/bin.
86
87Sometimes you need to perform this step after syncing:
88* `external/ltp$ make distclean`
89Otherwise, build will fail.
90
91In order to simulate the exact environment that VTS will be creating for each
92of these tests, you can set the following environment variables before you run
93the test. This is very useful if the test itself depends on some of these
94variables to be set appropriately.
95
96* `adb root && adb shell`
97
98In the root shell on device:
99* `mkdir -p /data/local/tmp/ltp/tmp/ltptemp`
100* `mkdir -p /data/local/tmp/ltp/tmp/tmpbase`
101* `mkdir -p /data/local/tmp/ltp/tmp/tmpdir`
102* `restorecon -F -R /data/local/tmp/ltp`
103* `export TMP=/data/local/tmp/ltp/tmp`
104* `export LTPTMP=/data/local/tmp/ltp/tmp/ltptemp`
105* `export LTP_DEV_FS_TYPE=ext4`
106* `export TMPBASE=/data/local/tmp/ltp/tmp/tmpbase`
107* `export TMPDIR=/data/local/tmp/ltp/tmp/tmpdir`
108* `export LTPROOT=/data/local/tmp/ltp`
109
110For running 64-bit tests:
111* `export PATH=/data/nativetest64/ltp/testcases/bin:$PATH`
112
113Or For running 32-bit tests:
114* `export PATH=/data/nativetest/ltp/testcases/bin:$PATH`
115
116How do I enable or disable tests from the LTP build?
117----------------------------------------------------
118
119Tests are disabled from the LTP build by adding them to
120external/ltp/android/tools/disabled_tests.txt. Many tests have been added to
121this file over time. Some of them are not applicable to Android and therefore
122should not be built. Others were disabled here because they were failing at one
123point in time for reasons unknown.
124
125To make a change to what is built in LTP, add or remove an entry in this file,
126and then update the Android-specific build files for LTP, mentioned above:
127
128* `external/ltp/android/Android.ltp.mk`, for LTP modules built in make
129* `external/ltp/gen.bp`, for LTP modules built in soong
130* `external/ltp/android/ltp_package_list.mk`, which lists all LTP modules that get pulled into VTS
131
132You can update these files manually, or you can run a script which regenerates
133these files from scratch, external/ltp/android/tools/gen_android_build.sh.
134
135How do I enable or disable tests from VTS LTP?
136----------------------------------------------
137
138In addition to whether modules are built in external/ltp, it is also necessary
139to configure the VTS harness for LTP to determine which tests are in the stable
140set, the staging set, or disabled. Note that being disabled in VTS does not
141affect whether the test is built, but rather determines whether it is run at
142all as part of the stable or staging sets.
143
144The file test/vts-testcase/kernel/ltp/configs/stable_tests.py lists tests that
145will run as part of VTS stable (VtsKernelLtp). The
146test/vts-testcase/kernel/ltp/configs/disabled_tests.py file lists tests that
147are runtime disabled in VTS. If a test is not listed in either of these files,
148but is enabled in the build in external/ltp, then it is in the staging set
149(VtsKernelLtpStaging).
150
151When a test is enabled for the first time in VTS it should be in the staging
152set. The behavior of the test will be observed over a period of time and ensure
153the test is reliable. After a period of time (a week or two) it will be moved
154to the stable set.
155
156Tests that will never be relevant to Android should be disabled from the build
157in external/ltp. Tests that are (hopefully) temporarily broken should be
158runtime disabled in VTS. The staging and stable sets should normally all be
159passing. If something is failing there it should either be fixed with priority
160or disabled until it can be fixed.
161
162How do I see or get notified about recent VTS LTP results?
163----------------------------------------------------------
164
165The internal portal at go/vts-web shows results for the continuous VTS testing
166done on internal devices. By adding tests such as VtsKernelLtp or
167VtsKernelLtpStaging to your favorites you will get email notifications whenever
168failures are seen.  Be warned, the testing iterates continuously and the
169notification emails can generate a lot of traffic.
170
171Test results are also gathered by Linaro and may be seen
172[here](https://qa-reports.linaro.org/android-lkft/).
173
174Help! The external/ltp build is failing!
175----------------------------------------
176
177Try doing a make distclean inside of external/ltp. If an upgrade to LTP has
178recently merged or the build files were recently updated, stale files in
179external/ltp can cause build failures.
180
181What outstanding issues exist?
182------------------------------
183
184The hotlist for LTP bugs is [ltp-todo](https://buganizer.corp.google.com/hotlists/733268).
185
186When you begin working on an LTP bug please assign the bug to yourself so that
187others know it is being worked on.
188
189Testing x86_64
190--------------
191
192It is not advisable to run LTP tests directly on your host unless you are fully
193aware of what the tests will do and are okay with it. These tests may
194destabilize your box or cause data loss. If you need to run tests on an x86
195platform and are unsure if they are safe you should run them in emulation, in a
196virtualized environment, or on a dedicated development x86 platform.
197
198Sending Fixes Upstream
199----------------------
200
201The mailing list for LTP is located
202[here](https://lists.linux.it/listinfo/ltp). Some standard kernel guidelines
203apply to sending patches; they should be checkpatch (scripts/checkpatch.pl in
204the kernel repository) clean and sent in plain text in canonical patch format.
205One easy way to do this is by using git format-patch and git send-email.
206
207There is an #LTP channel on freenode. The maintainer Cyril Hrubis is there (his
208nick is metan).
209
210Merging Fixes
211------------------------
212
213When possible please merge fixes upstream first. Then cherrypick the change
214onto aosp/master in external/ltp.
215
216