EDITORIAL

In fact, before writing submit patches, probably need to talk about the open source community begins operation models and processes, and to speak at how to participate in discussions and some of the considerations in the open source community, but because of content restrictions, can not expand here about. But since submitting patches have been involved in exchanges with other participants, I still talk about the submission patch things to note:

• Please check carefully before submitting patches patches, and double-check (this tool will be mentioned later) through checkpatch.pl tools to ensure the correctness of the submitted up (after all, can not be withdrawn after the message has been sent);
• Before a question or submit a patch, be sure to access to relevant information, to ensure that they thoroughly understand this already, ask questions or submit patches really be considered "problem" (at least appears to be their own problem). Mainly to avoid their own do not understand anything mouth and asked, then found some low-level problems.
• Please follow the rules of customary LTP submit patches. Such as the title general [LTP] [PATCH xx] theme, in fact, this is very simple, take a look at how others submitted after the subscription mailing list.
• Have a good idea, as far as possible to reflect the way the code, speech is pale ( "show me the code").
• Try to discuss the issue well-founded, polite, everyone cheerful discussion. Do not argue, there are views can be properly debated, must have a basis (evidence), not to abuse (the whole world is watching participants are Kazakhstan).

Ah, if you still afraid of problems, so this mailing list or see more of communication of other people right.

Patch submission

1. First make yourself a bugfix, with testcases / kernel / syscalls / open / open01.c A Case Study

static void setup(void)
{
        SAFE_MKDIR(TEST_DIR, 0755);
}

static void cleanup(void)
{
        if (fd > 0)
                SAFE_CLOSE(fd);
}

setup () TEST_DIR created by mkdir (TEST_DIR), then the cleanup () requires rmdir (TEST_DIR) (Oh, chances are it is really a problem).

2. modify, add SAFE_RMDIR () deletes a directory

static void cleanup(void)
{
        if (fd > 0)
                SAFE_CLOSE(fd);

        SAFE_RMDIR(NULL, TEST_DIR);
}

3. Submit commit
1) git branch see ensure the master branch, if not performing git checkout master

2) git add testcases/kernel/syscalls/open/open01.c

3) git commit
where it fills a commit, the following format

bugfix for open/open01.c

Add SAFE_RMDIR(NULL, TEST_DIR) to cleanup TEST_DIR.

Signed-off-by: Bixuan Cui <[email protected]>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#       modified:   testcases/kernel/syscalls/open/open01.c

The first line is the commit title, concise description of the commit is doing;
The third line is the commit content, title and content separated from his party, and then tell the commit action, in accordance with what is wrong before the phenomenon of individuals to their problem analysis, commit effect and the final effect ( because of this relatively simple, one-line description, do not worry representation is not clear, because the maintainer you see a line of code, it is estimated you do not need to say anything you want to know what to do)
is the fifth line of the declaration commit, and content separated from his party, the general on the final surface, is their name and email friends (be sure to bring Oh, you find a problem ^ _ ^ ).

4) After you save can be used git commit -amend continue to modify oh.

5）git format-patch -1 -o .
generation patch, -1 indicates a recent commit, -o specified directory generated. Finally generated 0001-bugfix-for-open-open01.c.patch

6) on the patch to be modified:
a.

Subject: [PATCH] bugfix for open/open01.c

Change

Subject: [LTP][PATCH] syscalls/open: bugfix for open/open01.c

Description, these two must reflect, [LTP] represents LTP community, syscalls / open representation of syscalls open the following modifications.

b. if it is their second edition revised, please change

Subject: [LTP][PATCH v2] syscalls/open: bugfix for open/open01.c

and

Signed-off-by: Bixuan Cui <[email protected]>
---
Here add (v2-> v1: modify the contents of)
 testcases/kernel/syscalls/open/open01.c | 2 ++
 1 file changed, 2 insertions(+)

c. If two connected commit (in fact, is not expected to write to several beginners commit, because the general use case is submitted or major changes in time, then you do not have to see this article), then git format-patch -2 -o. or manually modify [PATCH v1] [PATCH v2]

7) use of linux checkpatch.pl check patch:
git Please download linux any version (since learning ltp, linux codes have to learn ah)

../linux/scripts/checkpatch.pl -f 0001-bugfix-for-open-open01.c.patch
ERROR: trailing whitespace
#24: FILE: 0001-bugfix-for-open-open01.c.patch:24:
+ $

ERROR: trailing whitespace
#26: FILE: 0001-bugfix-for-open-open01.c.patch:26:
+-- $

total: 2 errors, 0 warnings, 28 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

NOTE: Whitespace errors detected.
      You may wish to use scripts/cleanpatch or scripts/cleanfile

0001-bugfix-for-open-open01.c.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Ah, patch of 24 and 26 lines, more than $, in fact, space, vim open patch, delete the extra space, make sure to check -f is not being given. like this

../linux/scripts/checkpatch.pl -f 0001-bugfix-for-open-open01.c.patch
total: 0 errors, 0 warnings, 28 lines checked

0001-bugfix-for-open-open01.c.patch has no obvious style problems and is ready for submission.

8) and then check again the whole patch, carefully drop;
9) send a message to the mailing list
git send-email –to [email protected] 0001-bugfix-for-open-open01.c.patch

At this point, you can look ltp mailing lists without their own e-mail friends, general twenty-three days there will be a response.

LTP how to quickly find the bug (To submit patches and community learning exchanges)

Personal summary is very easy to find a bug, submit a patch of points:

1. Download the latest release version of linux test execution ltp
Individual virtual machines can be installed, and then to replace the latest core executes the test ltp. Because linux interface to change or modify the properties, ltp unable to update (in fact ltp maintenance of the core new features and interface changes has always been to supplement the participants), this time will find new TFAIL or TBROK use cases, combined with a careful analysis of modified linux under will be able to find the problem.

2. Execute LTP in different architectures
LTP version, more assurance X86 platform, but also provide compatibility for other architectures, but to really test rarely used. Many of the individual patch repair ltp are part of cases of arm (arm64) platform compatibility is not a problem with the recent comparison of fire RISC-V linux gradually provide support, ltp have to keep up, the platform is estimated there will be problems.

3. Submit your own use case
Personal always concerned about the latest information changelog under linux community, as well as lwn community, network interface changes and new features of linux, new use cases for these functions, it is easy to be received ( submitted individual layer properties with Example xattr code).

4. Other
framework for the implementation of ltp feeling troublesome place, can be optimized.

Personal recommendations or submit start with bugfix.