public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2] syscalls: add syscall syncfs test
Date: Mon, 18 Feb 2019 12:57:46 +0100	[thread overview]
Message-ID: <20190218115746.GA25025@rei.lan> (raw)
In-Reply-To: <4cae2a11-47c2-c319-19cf-9a8fecc7793d@google.com>

Hi!
> >> Thanks for the pointers. IIUC, you are referring to following change:
> >>
> >> -       TEST(syncfs(fd));
> >> +       TEST(tst_syscall(__NR_syncfs, fd));
> >>
> >> If yes, then I will incorporate it.
> > 
> > The most complete solution is configure check + fallback definition.
> > 
> > Have a look at:
> > 
> > include/lapi/execveat.h
> > m4/ltp-execveat.m4
> > configure.ac
> 
> For tests in testcases/kernel/syscalls, should the tests typically 
> directly call the syscall? I'd think this is preferable to the use of C 
> library wrappers as these tests (by their location in the tree) seem to 
> be focused on the syscall functionality in the kernel.

My take on this is that for a functional testing we really have to test
the kernel together with the library that wraps the syscalls because
otherwise bugs are bound to happen such as these:

https://sourceware.org/bugzilla/show_bug.cgi?id=23069
https://sourceware.org/bugzilla/show_bug.cgi?id=23579

And I always cared about syscalls being correct on the C library level.

I guess that for most of the syscalls that are just thin wrappers it
does not matter since these just prepare the parameters and jump to the
kernel, but in certain cases libc does quite a lot of work which is
sometimes complex code I do not want to replicate that unless really
needed. And with that I think that it's actually much easier to go with
the libc API whenever possible rather than reviewing the libc code each
time we write a testcase.

Does that sound reasonable to you?

-- 
Cyril Hrubis
chrubis@suse.cz

  parent reply	other threads:[~2019-02-18 11:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15  7:17 [LTP] [PATCH v2] syscalls: add syscall syncfs test Sumit Garg
2019-02-15  7:55 ` Xiao Yang
2019-02-15 11:58   ` Sumit Garg
2019-02-15 12:16     ` Cyril Hrubis
2019-02-15 13:18       ` Sumit Garg
2019-02-15 13:22         ` Cyril Hrubis
2019-02-15 13:25           ` Cyril Hrubis
2019-02-15 13:51             ` Sumit Garg
2019-02-16  0:17           ` Steve Muckle
2019-02-18  7:52             ` Sumit Garg
2019-02-18 12:24               ` Cyril Hrubis
2019-02-18 11:57             ` Cyril Hrubis [this message]
2019-02-19 23:15               ` Steve Muckle
2019-02-20 13:14                 ` Cyril Hrubis
2019-02-20 15:12                   ` Cyril Hrubis
2019-02-22 19:58                     ` Steve Muckle
2019-02-19  6:44   ` Sumit Garg
2019-02-21  7:08     ` Sumit Garg
2019-02-15  8:42 ` Amir Goldstein
2019-02-15 13:03   ` Cyril Hrubis
2019-02-15 13:38   ` Sumit Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190218115746.GA25025@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox