From: Petr Vorel <pvorel@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] tst_device: add new tst_dev_sync
Date: Thu, 9 Jan 2020 09:06:17 +0100 [thread overview]
Message-ID: <20200109080617.GA10609@dell5510> (raw)
In-Reply-To: <CAEemH2dUhpixZoorh_-H1CHenk9-XG9ZocjHB30RqzW_Kb0dCw@mail.gmail.com>
Hi Li,
> > > You would need to define _GNU_SOURCE at the top of each test that uses
> > > it otherwise the definition is not exposed.
> > Yep :(. I join to Cyril's vote for raw syscall.
> > BTW please test it with travis or locally build.sh script (which adds
> > -Werror=implicit-function-declaration).
> I'd go with syscall(__NR_syncfs, fd) in the tst_device.h and
> define _GNU_SOURCE in relevant test cases.
> The reason why not use tst_syscall() is that involves a new compile error
> of tst_brk, and it can not get rid of errors only via include tst_test.h
> file.
+1. (I already tested it and replied to that patch).
I wonder if this is a pattern (try to avoid _GNU_SOURCE code in the library, if
needed use syscall() instead).
I'm asking because I still plan to write v2 for library API writing guidelines
docs patch.
BTW you didn't update wiki after merging eca0fa3c3.
I did it :) (we need some maintainer docs as well, we keep with Cyril to update
wiki and (sometimes) maintain patchwork for other maintainers).
BTW there is git repository for each git on github (our [2]), I maintain it with
shell script.
> > I guess we should work on travis CI integration so we don't have to push
> > it to
> > travis manually [1].
> That's a good proposal. I feel so sorry for pushing without a compiling in
> Travis this time, because I thought the code is good enough but ...
No problem :).
Kind regards,
Petr
[1] https://patchwork.ozlabs.org/patch/1166786/
[2] https://github.com/linux-test-project/ltp.wiki.git
next prev parent reply other threads:[~2020-01-09 8:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-07 7:13 [LTP] [PATCH] tst_device: add new tst_dev_sync Li Wang
2020-01-07 10:11 ` Cyril Hrubis
2020-01-08 10:46 ` Li Wang
2020-01-08 11:25 ` Petr Vorel
2020-01-08 11:30 ` Petr Vorel
2020-01-08 11:35 ` Cyril Hrubis
2020-01-08 11:39 ` Li Wang
2020-01-08 11:41 ` Cyril Hrubis
2020-01-08 11:45 ` Petr Vorel
2020-01-09 6:59 ` Li Wang
2020-01-09 8:06 ` Petr Vorel [this message]
2020-01-09 9:49 ` Cyril Hrubis
2020-01-09 10:10 ` Petr Vorel
2020-01-09 7:37 ` Yang Xu
2020-01-09 8:46 ` Petr Vorel
2020-01-09 9:56 ` Yang Xu
2020-01-09 10:05 ` Petr Vorel
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=20200109080617.GA10609@dell5510 \
--to=pvorel@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