link/link02: Convert to new API

Signed-off-by: tangmeng <tangmeng@uniontech.com>
---
 testcases/kernel/syscalls/link/link02.c | 102 ++++++------------------
 1 file changed, 23 insertions(+), 79 deletions(-)

--
2.20.1

Tang Meng,

Plz stop sending the same patch again and again. It looks
like an email bomb to the mailing list.

If you are not sure the patch being deliver correctly, you
can try wait a moment and check https://lists.linux.it/listinfo/ltp

Hi!
> Plz stop sending the same patch again and again. It looks
> like an email bomb to the mailing list.

Partly my mistake, when I looked at the list of patches for moderation I
didn't realized that this is one patch send many times, sorry for that.

However Tang if you email to a ML is held for moderation please wait
instead of resending, I do reviewe the held emails nearly daily so the
delay shouldn't be worse than a day or two. Also if you sing up to the
ML the emails would go right through.

Hi, Cyril Hrubis and LI Wang!


First of all, I want to say that I am extremely sorry.
Since it was the first time I submitted a patch here, there were many unfamiliar and misunderstandings in the process, which led to multiple submissions.
I will take care to avoid this problem in the future


-- 
Regards,
TangMeng
------------------ Original ------------------
From: &nbsp;"Cyril Hrubis"<chrubis@suse.cz&gt;;
Date: &nbsp;Mon, Oct 25, 2021 04:10 PM
To: &nbsp;"Li Wang"<liwang@redhat.com&gt;; 
Cc: &nbsp;"tangmeng"<tangmeng@uniontech.com&gt;; "LTP List"<ltp@lists.linux.it&gt;; 
Subject: &nbsp;Re: [LTP] [PATCH] link/link02: Convert to new API

&nbsp;

Hi!
&gt; Plz stop sending the same patch again and again. It looks
&gt; like an email bomb to the mailing list.

Partly my mistake, when I looked at the list of patches for moderation I
didn't realized that this is one patch send many times, sorry for that.

However Tang if you email to a ML is held for moderation please wait
instead of resending, I do reviewe the held emails nearly daily so the
delay shouldn't be worse than a day or two. Also if you sing up to the
ML the emails would go right through.

Hi Meng,


> -static void verify_link(void)
> +static void verify_link02(void)
>  {
>         struct stat fbuf, lbuf;
>
>         TEST(link(OLDPATH, NEWPATH));
>
> -       if (TEST_RETURN == 0) {
> -               SAFE_STAT(cleanup, OLDPATH, &fbuf);
> -               SAFE_STAT(cleanup, NEWPATH, &lbuf);
> +       if (TST_RET == 0) {
> +               SAFE_STAT(OLDPATH, &fbuf);
> +               SAFE_STAT(NEWPATH, &lbuf);
>                 if (fbuf.st_nlink > 1 && lbuf.st_nlink > 1 &&
>                     fbuf.st_nlink == lbuf.st_nlink) {
> -                       tst_resm(TPASS, "link("OLDPATH","NEWPATH") "
> +                       tst_res(TPASS, "link("OLDPATH","NEWPATH") "
>                                  "returned 0 and link counts match");
>                 } else {
> -                       tst_resm(TFAIL, "link("OLDPATH","NEWPATH")
> returned 0"
> +                       tst_res(TFAIL, "link("OLDPATH","NEWPATH") returned
> 0"
>                                  " but stat lin count do not match %d %d",
>                                  (int)fbuf.st_nlink, (int)lbuf.st_nlink);
>                 }
> -               SAFE_UNLINK(cleanup, NEWPATH);
>         } else {
> -               tst_resm(TFAIL | TTERRNO,
> +               tst_res(TFAIL | TTERRNO,
>                          "link("OLDPATH","NEWPATH") returned %ld",
> -                        TEST_RETURN);
> -       }
>

Generally looks good, but I personally hope to decrease the
layers of brace nesting by reordering the if-conditions.

Something logic like this maybe better:

        TEST(link(OLDPATH, NEWPATH));
        if (TST_RET == -1) {
                ...
        }

        SAFE_STAT(OLDPATH, &fbuf);
        SAFE_STAT(NEWPATH, &lbuf);

        if (fbuf.st_nlink > 1 && fbuf.st_nlink == lbuf.st_nlink) {
                ...
        } else {
               ...
        }



> -}
> -
> -int main(int ac, char **av)
> -{
> -       int lc;
> -
> -       tst_parse_opts(ac, av, NULL, NULL);
> -
> -       setup();
> -
> -       for (lc = 0; TEST_LOOPING(lc); lc++) {
> -               tst_count = 0;
> -               verify_link();
> +                        TST_RET);
>         }
> -
> -       cleanup();
> -       tst_exit();
>  }
>
>  static void setup(void)
>  {
> -       tst_sig(NOFORK, DEF_HANDLER, cleanup);
> -
> -       TEST_PAUSE;
> -
> -       tst_tmpdir();
> -
> -       SAFE_TOUCH(cleanup, OLDPATH, 0700, NULL);
> +       SAFE_TOUCH(OLDPATH, 0700, NULL);
>  }
>
>  static void cleanup(void)
>  {
> -       tst_rmdir();
> +    SAFE_UNLINK(NEWPATH);
>

I'd suggest moving this unlink() to verify_link02 to make test
options '-i N' happy.

Otherwise:

# ./link02 -i 2
tst_test.c:1365: TINFO: Timeout per run is 0h 05m 00s
link02.c:31: TPASS: link(oldpath,newpath) returned 0 and link counts match
link02.c:40: TFAIL: link(oldpath,newpath) returned -1: EEXIST (17)

 }
> +
> +static struct tst_test test = {
> +    .test_all = verify_link02,
> +    .setup = setup,
> +    .cleanup = cleanup,
> +    .needs_tmpdir = 1,
> +};
> --
> 2.20.1
>
>
>
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
>
>

> First of all, I want to say that I am extremely sorry.
> Since it was the first time I submitted a patch here, there were many
> unfamiliar and misunderstandings in the process, which led to multiple
> submissions.
>

Never mind, and thanks for sending patch!


> I will take care to avoid this problem in the future
>

And better to reply in plain text mode but not HTML format in email.
Which avoids showing messy code in different email clients.