From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/2] lib/tst_mkfs: new tst_mkfs_sized function for create appointed size fs
Date: Wed, 9 Mar 2016 18:43:37 +0100 [thread overview]
Message-ID: <20160309174337.GA32758@rei> (raw)
In-Reply-To: <2053304118.27813474.1457541005041.JavaMail.zimbra@redhat.com>
Hi!
> Sure, it's OK for me. And I think if we call it *fs_size, maybe make the user
> feel confused. The truth is it's the count of blocks, and only used for some
> fs. So maybe we can call it *extra_opts, means used after device name?
That is true, well the 'man mkfs' is confusing as well since it looks
like the size argument is supported generally by mkfs binaries...
And we should call it extra_opt, since it's just one option.
> So I will do this patch:
>
> 1. change tst_mkfs to
> void safe_mkfs(const int lineno, const char *fname, const char *dev,
> const char *fs_type, const char *const fs_opts[],
> const char *extra_opts)
>
> 2. add tst_mkfs into test.h:
> static inline void tst_mkfs(const int lineno, const char *fname, const char *dev,
> const char *fs_type, const char *const fs_opts[])
> {
> safe_mkfs(lineno, fname, dev, fs_type, fs_opts, NULL);
> }
>
> Does this you want?
Having two nearly identical *_mkfs() functions would be confusing as
well. I would have just changed the function prototype and fixed all the
testcases that use it (36 testcases if I'm counting right).
--
Cyril Hrubis
chrubis@suse.cz
next prev parent reply other threads:[~2016-03-09 17:43 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-08 13:35 [LTP] [PATCH 1/2] lib/tst_mkfs: new tst_mkfs_sized function for create appointed size fs Zorro Lang
2016-03-08 13:35 ` [LTP] [PATCH 2/2] mmap16: fix ETIMEDOUT error if test device is too large Zorro Lang
2016-03-09 2:22 ` Eryu Guan
2016-03-09 3:12 ` Zirong Lang
2016-03-09 13:07 ` [LTP] [PATCH 1/2] lib/tst_mkfs: new tst_mkfs_sized function for create appointed size fs Cyril Hrubis
2016-03-09 15:31 ` Zirong Lang
2016-03-09 15:52 ` Cyril Hrubis
2016-03-09 16:05 ` Zirong Lang
2016-03-09 16:09 ` Cyril Hrubis
2016-03-09 16:30 ` Zirong Lang
2016-03-09 17:43 ` Cyril Hrubis [this message]
2016-03-10 1:45 ` Zirong Lang
2016-03-10 10:04 ` Cyril Hrubis
2016-03-10 12:00 ` Zirong Lang
2016-03-10 12:19 ` Cyril Hrubis
2016-03-10 13:30 ` Zirong Lang
2016-03-10 14:06 ` Cyril Hrubis
2016-03-10 16:24 ` Zirong Lang
2016-03-14 17:15 ` Cyril Hrubis
2016-03-09 16:01 ` Zirong Lang
2016-03-09 13:09 ` Cyril Hrubis
2016-03-09 15:09 ` Zirong Lang
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=20160309174337.GA32758@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