From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v3 1/7] lib: Add library functions for sync related syscalls
Date: Wed, 20 Feb 2019 13:03:34 +0100 [thread overview]
Message-ID: <20190220120334.GA32140@rei> (raw)
In-Reply-To: <CAFA6WYN2f4iT85y5hJbk3m8zDkfgwi1kEKES59B2ZOOiS22YDA@mail.gmail.com>
Hi!
> > Maybe we just need a tst_dev_bytes_written() function that would return
> > the bytes written since the last call of the function so that we could
> > do:
> >
> > fd = SAFE_OPEN(...);
> >
> > tst_dev_blocks_written(tst_device.dev);
> >
> > tst_fill_fd(fd, 0, TST_MB, size_mb);
> >
> > TEST(fdsync(fd));
> >
> > if (TST_RET)
> > tst_brk(TFAIL | TTERRNO, "syncfd() failed with %i", TST_RET);
> >
> > written = tst_dev_blocks_written(tst_device.dev);
> >
> > SAFE_CLOSE(fd);
> >
> > if (written >= size_mb * TST_DEV_BLOCKS_IN_MB)
> > tst_res(TPASS, ...);
> > else
> > tst_res(TFAIL, ...);
> >
>
> Seems to be nicer approach. So rather than new file should I add
> tst_dev_bytes_written() function in "lib/tst_device.c" file?
Sounds good to me.
> > The test a bit longer, but the library functions are more reusable, if
> > you do 'git grep -B 1 SAFE_WRITE' you can see that the tst_fill_fd
> > function that loops over SAFE_WRITE could be used in a few places
> > already.
> >
>
> I am not able to locate tst_fill_fd function. Are you referring to
> tst_fill_file function? If yes, then we could split that function to
> create tst_fill_fd function.
There is none, I was trying to state that there are several places that
use the same pattern and that such function would be generally useful.
And yes, buiding tst_fill_file on the top of tst_fill_fd sounds like a
good approach.
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2019-02-20 12:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-19 9:28 [LTP] [PATCH v3 0/7] syscalls: add sync device test-cases Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 1/7] lib: Add library functions for sync related syscalls Sumit Garg
2019-02-19 14:06 ` Cyril Hrubis
2019-02-20 7:57 ` Sumit Garg
2019-02-20 12:03 ` Cyril Hrubis [this message]
2019-02-20 12:08 ` Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 2/7] syscalls: add syncfs() sync device test-case Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 3/7] syscalls/sync: add " Sumit Garg
2019-02-19 14:09 ` Cyril Hrubis
2019-02-20 8:20 ` Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 4/7] syscalls/fsync: " Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 5/7] syscalls/fdatasync: " Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 6/7] syscalls/sync_file_range: Use C library wrapper if present Sumit Garg
2019-02-19 14:19 ` Cyril Hrubis
2019-02-20 8:27 ` Sumit Garg
2019-02-19 9:28 ` [LTP] [PATCH v3 7/7] syscalls/sync_file_range: add sync device test-case Sumit Garg
2019-02-19 14:20 ` Cyril Hrubis
2019-02-20 8:34 ` 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=20190220120334.GA32140@rei \
--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