Lines Matching +full:commit +full:- +full:message +full:- +full:check
5 … https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines[Test Writing Guidelines],
6 https://github.com/linux-test-project/ltp/wiki/C-Test-API[C Test API].
8 This is a step-by-step tutorial on writing a simple C LTP test, where topics
20 -------------------------
31 ------------------
33 Git-clone the main LTP repository as described in
34 https://github.com/linux-test-project/ltp#quick-guide-to-running-the-tests[the +README.md+]
35 and change directory to the checked-out Git repository. We recommend installing the LTP
43 ------------------------------------------------------------------------------
45 ------------------------------------------------------------------------------
61 -------------------------------
69 repository to check for any existing usages of a system call.
74 Something the LTP excels at is ensuring bug-fixes are back ported to
82 syscall+ produces a result). It is a good idea to Git-clone the latest kernel
83 man-pages repository.
86 ------------------------------------------------------------------------------
87 $ git clone git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
88 ------------------------------------------------------------------------------
90 At the time of writing the difference between the latest man-pages release and
91 the +HEAD+ of the repository (usually the latest commit) is well over 100
93 Linux distribution, your man-pages package may well be years old. So as with
100 ---------------------------
107 ------------------------------------------------------------------------------
111 ------------------------------------------------------------------------------
118 ------------------------------------------------------------------------------
119 // SPDX-License-Identifier: GPL-2.0-or-later
128 * Non-trivial explanations of _how_ the code works should also go here.
129 * Include relevant links, Git commit hashes and CVE numbers.
144 ------------------------------------------------------------------------------
179 Before continuing we should compile this and check that the basics work. In
185 ------------------------------------------------------------------------------
186 # SPDX-License-Identifier: GPL-2.0-or-later
195 ------------------------------------------------------------------------------
209 --------------------------------------------------------------------------------
210 statx01: CFLAGS += -pthread
211 --------------------------------------------------------------------------------
217 --------------------------------------------------------------------------------
220 --------------------------------------------------------------------------------
224 _syscalls_ test group (remember +./runltp -f syscalls+ from the +README.md+?). For
229 --------------------------------------------------------------------------------
238 --------------------------------------------------------------------------------
253 --------------------------------------------------------------------------------
254 $ git checkout -b statx01 master
255 --------------------------------------------------------------------------------
258 commit make sure you have configured Git correctly. You need to at least set
259 your Name and e-mail address in +~/.gitconfig+, but there are some other
264 --------------------------------------------------------------------------------
267 email = sjane@e-mail.address
272 --------------------------------------------------------------------------------
274 Obviously you need to at least change your name and e-mail. The SMTP server is
275 useful for +git send-email+, which we will discuss later. The editor value is
276 used for things like writing commits (without the +-m+ option).
279 --------------------------------------------------------------------------------
280 $ git add -v :/testcases/kernel/syscalls/statx :/runtest/syscalls
281 $ git commit -m "statx01: Add new test for statx syscall"
282 --------------------------------------------------------------------------------
285 file. It is good practice to commit early and often. Later on we will do a
286 Git-rebase, which allows us to clean up the commit history. So don't worry
287 about how presentable your commit log is for now. Also don't hesitate to
293 a mess, Git-reflog and Git-reset, will usually get you out of it. If you also
301 +TBROK+. Try changing it do so (see +doc/test-writing-guidelines.txt+ or
302 https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines[the
305 3.2 Check Git ignores the executable
310 3.3 Run make check
313 Check coding style with `make check`
314 …(more in https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#21-c-coding-style[…
322 -----------------------
340 Note that we don't use the system-call-identifier value available in
349 --------------------------------------------------------------------------------
353 * Check if statx exists and what error code it returns when we give it dodgy
398 --------------------------------------------------------------------------------
427 The final test should do a check during configuration (i.e. when we run
438 --------------------------------------------------------------------------------
459 --------------------------------------------------------------------------------
466 We check whether the return value indicates success and if it doesn't also
467 check the value of +errno+. The last call to +tst_res+ includes +TERRNO+,
469 addition to the message we have provided. Note that it uses the current value
487 https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines[test
502 ---------------------------
526 --------------------------------------------------------------------------------
530 * Check if statx exists and what error code it returns when we give it dodgy
531 * data. Then stat a file and check it returns success.
545 --------------------------------------------------------------------------------
558 --------------------------------------------------------------------------------
591 --------------------------------------------------------------------------------
611 if I create and open a file, then create a hard-link to it, then call open
612 again on the hard-link, then 'stat' the file".
615 --------------------------------------------------------------------------------
655 --------------------------------------------------------------------------------
660 https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines[test
676 +TBROK+. Instead they just print an error message with +TWARN+.
678 It is not entirely necessary to check if the file descriptors have a none zero
684 5.1 Check statx returns the correct number of hard links
689 5.2 Git-branch
694 check the behavior has not been changed by accident.
697 -----------------
700 one. Firstly we check if an error is returned when bad arguments are provided
701 and secondly we check what happens when we stat an actual file. Quite often it
711 --------------------------------------------------------------------------------
754 --------------------------------------------------------------------------------
770 Were you paying attention? Also see the output of +make check+.
776 example, you could check stx_btime is correct (possibly only to within a
780 Alternatively you could check that +stx_dev_major+ and +stx_dev_minor+ are set
783 https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines#2214-testing-with-a-block-de…
791 ---------------------------------
798 +make check-statx01+ or + make check+ in the test's directory. Again, we use
800 branch, this will allow you to reshape your commit history without fear.
803 our commit history. In its current form the test only really needs a single
804 commit, but if you have been using Git correctly then you should have
805 many. The main reason we want to compress it to a single commit, is to make
806 the LTP's Git-log readable. It also allows us to write a coherent description
808 test description in the code will probably make the commit message redundant.
810 Anyway, as an example, we shall look at my personal commit history from this
812 repository. First lets look at the commit history since we branched from
816 --------------------------------------------------------------------------------
817 $ git log --oneline master..HEAD
818 152d39fe7 (HEAD -> tutorial-rebase2, tutorial-rebase) tutorial: Start Submitting patch section
822 d784b1e85 test-writing-guidelines: Remove old API argument
824 1e24a5fb5 (me/tutorial-rebase) fixup! tutorial
832 5ca627b78 tutorial: Add a step-by-step C test tutorial
833 --------------------------------------------------------------------------------
837 branch is +tutorial-rebase2+ which I just created. I have already done one
841 As usual my commit history is starting to look like a bit of mess! There is
842 even a commit in there which should not be in the this branch (Remove old API
849 +tutorial:+ into the bottom commit.
852 --------------------------------------------------------------------------------
853 $ git rebase -i 5ca627b78\^
855 --------------------------------------------------------------------------------
857 This begins an interactive 'rebase' where commit 5ca6427b78 is the earliest
858 commit we want to edit. The +^+ symbol after the commit hash, specifies the
859 commit before this one. The interactive 'rebase' command takes the last commit
861 non-inclusive range).
869 --------------------------------------------------------------------------------
870 pick 5ca627b78 tutorial: Add a step-by-step C test tutorial
880 pick d784b1e85 test-writing-guidelines: Remove old API argument
885 --------------------------------------------------------------------------------
887 The last commit from Git-log is shown at the top. The left hand column
888 contains the commands we want to run on each commit. +pick+ just means we
889 re-apply the commit as-is. We can reorder the lines to apply the commits in a
895 we pick a point in the commit history, undo all those commits before that
900 allows you to edit a single commit's message. The 'fixup' command 'squashes' a
901 commit into the commit above/preceding it, merging the two commits into
902 one. The commit which has +fixup+ applied has its commit message deleted. If
903 you think a commit might have something useful in its message then you can use
907 --------------------------------------------------------------------------------
908 reword 5ca627b78 tutorial: Add a step-by-step C test tutorial
921 pick d784b1e85 test-writing-guidelines: Remove old API argument
923 --------------------------------------------------------------------------------
925 So all the commits marked with +fixup+ will be re-played by Git immediately
926 after 5ca62 at the top. A new commit will then be created with the amalgamated
927 changes of all the commits and 5ca62's log message. It turns out that I didn't
929 forget the +Signed-off-by:+ line.
931 I could now do the same for the commits to the +statx+ test, making the commit
932 message prefixes consistent. However I am not actually going to submit the
936 apart a commit. It is also possible using Git-rebase by marking a line with
937 +edit+. This will pause Git just after replaying the marked commit. You can
938 then use a 'soft' Git-reset to bring the selected commit's changes back into
939 the 'index' where you are then able to un-stage some parts before
940 re-committing.
942 You can also use +edit+ and +git commit --amend+ together to change a commit
946 So now that the commit history has been cleaned up, we need to submit a patch
951 Just before we create the patch, we need to check that our changes will still
956 --------------------------------------------------------------------------------
959 $ git checkout tutorial-rebase2
961 --------------------------------------------------------------------------------
969 --------------------------------------------------------------------------------
971 cve-2016-7117: LDFLAGS += -lpthread
973 cve-2014-0196: LDFLAGS += -lpthread -lutil -lrt
974 cve-2016-7117: LDFLAGS += -lpthread -lrt
975 >>>>>>> 4dbfb8e79... Add -lrt
976 --------------------------------------------------------------------------------
982 --continue+.
984 In order to create a patch e-mail we use https://git-scm.com/docs/git-format-patch[+git format-patc…
985 we can then send that e-mail using https://git-scm.com/docs/git-send-email[+git send-email+].
986 It is also possible to import the patch (+mbox+) file into a number of e-mail programs.
989 --------------------------------------------------------------------------------
990 $ git format-patch -1 -v 2 -o output --to ltp@lists.linux.it fd3cc8596
991 output/v2-0001-tutorial-Add-a-step-by-step-C-test-tutorial.patch
992 --------------------------------------------------------------------------------
994 The first argument +-1+ specifies we want one commit from fd3cc8596
995 onwards. If we wanted this commit and the one after it we could specify +-2+
998 This is my second patch submission so I have used +-v 2+, which indicates this
999 is the second version of a patch set. The +-o+ option specifies the output
1000 directory (literally called +output+). The +--to+ option adds the +To:+ e-mail
1003 We can then send this patch with the following command sans +--dry-run+.
1006 --------------------------------------------------------------------------------
1007 $ git send-email --dry-run output/v2-0001-tutorial-Add-a-step-by-step-C-test-tutorial.patch
1008 --------------------------------------------------------------------------------
1011 would do if this weren't a dry-run. In order for this to work you have to have
1013 mailing list under the same e-mail address you have configured in Git. You can
1017 --------------------
1045 --------------
1065 multi-process or multi-threaded testing. The LTP library functions work inside
1069 https://github.com/linux-test-project/ltp/wiki/C-Test-API[C Test API],
1071 https://github.com/linux-test-project/ltp/wiki/C-Test-API#17-fork-ing[1.7 Fork()-ing] to
1072 https://github.com/linux-test-project/ltp/wiki/C-Test-API#110-signals-and-signal-handlers[1.10 Sign…
1073 https://github.com/linux-test-project/ltp/wiki/C-Test-API#114-thread-safety-in-the-ltp-library[1.14…