From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Jan Tulak <jtulak@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 05/12] mkfs: extend opt_params with a value field
Date: Tue, 25 Apr 2017 05:13:26 +0200 [thread overview]
Message-ID: <20170425031326.GI28800@wotan.suse.de> (raw)
In-Reply-To: <20170423185503.31415-6-jtulak@redhat.com>
On Sun, Apr 23, 2017 at 08:54:56PM +0200, Jan Tulak wrote:
> Add a new field int opt_params - value,
Agreed.
> which is filled with user input.
It sounds to me its more than that, its the default value which will be used should
not user input for the option be specified, and if user input value is provided it
will be the passed user input value. If the final value for the respective option.
?
> Signed-off-by: Jan Tulak <jtulak@redhat.com>
> ---
> mkfs/xfs_mkfs.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> index 513e106..c2ffd91 100644
> --- a/mkfs/xfs_mkfs.c
> +++ b/mkfs/xfs_mkfs.c
> @@ -128,6 +128,12 @@ uint64_t sectorsize;
> * Filled raw string from the user, so we never lose that information e.g.
> * to print it back in case of an issue.
> *
> + * value OPTIONAL
> + * The value that is to be used if the given subopt is not specified at all.
It seems to be more than that ?
> + * This is filled with user input
This is a bit confusing, isn't it first the default value should no user input
value be passed ? And finally if user input value is passed only then will this
be that value ?
> and anything you write here now is
> + * overwritten if user specifies the subopt. (If the user input is a string
> + * and not a number, this value is set to a positive non-zero number.)
> + *
> * !!! NOTE ==================================================================
> *
> * If you are adding a new option, or changing an existing one,
> @@ -152,6 +158,7 @@ struct opt_params {
> uint64_t maxval;
> uint64_t flagval;
> const char *raw_input;
> + uint64_t value;
> } subopt_params[MAX_SUBOPTS];
> } opts[MAX_OPTS] = {
> #define OPT_B 0
It would seem rather unfair to define this this but not use it in the patch ?
Luis
next prev parent reply other threads:[~2017-04-25 3:13 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-23 18:54 [PATCH 00/12] mkfs: save user input into opts table Jan Tulak
2017-04-23 18:54 ` [PATCH 01/12] mkfs: Save raw user input field to the opts struct Jan Tulak
2017-04-25 17:38 ` Eric Sandeen
2017-04-23 18:54 ` [PATCH 02/12] mkfs: rename defaultval to flagval in opts Jan Tulak
2017-04-25 16:52 ` Eric Sandeen
2017-04-26 7:30 ` Jan Tulak
2017-04-26 13:02 ` Eric Sandeen
2017-04-26 13:20 ` Jan Tulak
2017-04-23 18:54 ` [PATCH 03/12] mkfs: remove intermediate getstr followed by getnum Jan Tulak
2017-04-25 17:37 ` Eric Sandeen
2017-04-26 7:40 ` Jan Tulak
2017-04-26 13:13 ` Eric Sandeen
2017-04-23 18:54 ` [PATCH 04/12] mkfs: merge tables for opts parsing into one table Jan Tulak
2017-04-25 3:04 ` Luis R. Rodriguez
2017-04-25 7:45 ` Jan Tulak
2017-04-25 13:28 ` Eric Sandeen
2017-04-26 1:38 ` Luis R. Rodriguez
2017-04-26 1:45 ` Luis R. Rodriguez
2017-04-26 2:00 ` Eric Sandeen
2017-04-26 8:01 ` Luis R. Rodriguez
2017-04-26 8:24 ` Jan Tulak
2017-04-26 8:21 ` Luis R. Rodriguez
2017-04-26 8:38 ` Jan Tulak
2017-04-25 21:45 ` Eric Sandeen
2017-04-26 4:09 ` Eric Sandeen
2017-04-26 8:14 ` Jan Tulak
2017-04-23 18:54 ` [PATCH 05/12] mkfs: extend opt_params with a value field Jan Tulak
2017-04-25 3:13 ` Luis R. Rodriguez [this message]
2017-04-25 8:04 ` Jan Tulak
2017-04-25 9:39 ` Jan Tulak
2017-04-26 1:04 ` Luis R. Rodriguez
2017-04-26 8:51 ` Jan Tulak
2017-04-26 1:10 ` Luis R. Rodriguez
2017-04-26 2:50 ` Eric Sandeen
2017-04-26 8:52 ` Jan Tulak
2017-04-23 18:54 ` [PATCH 06/12] mkfs: create get/set functions for opts table Jan Tulak
2017-04-25 3:40 ` Luis R. Rodriguez
2017-04-25 8:11 ` Jan Tulak
2017-04-26 1:43 ` Luis R. Rodriguez
2017-04-23 18:54 ` [PATCH 07/12] mkfs: save user input values into opts Jan Tulak
2017-04-25 5:19 ` Luis R. Rodriguez
2017-04-25 8:16 ` Jan Tulak
2017-04-26 1:47 ` Luis R. Rodriguez
2017-04-23 18:54 ` [PATCH 08/12] mkfs: replace variables with opts table: -b,d,s options Jan Tulak
2017-04-25 5:27 ` Luis R. Rodriguez
2017-04-25 5:30 ` Luis R. Rodriguez
2017-04-25 8:37 ` Jan Tulak
2017-04-26 0:45 ` Luis R. Rodriguez
2017-04-26 9:09 ` Jan Tulak
2017-04-23 18:55 ` [PATCH 09/12] mkfs: replace variables with opts table: -i options Jan Tulak
2017-04-23 18:55 ` [PATCH 10/12] mkfs: replace variables with opts table: -l options Jan Tulak
2017-04-23 18:55 ` [PATCH 11/12] mkfs: replace variables with opts table: -n options Jan Tulak
2017-04-23 18:55 ` [PATCH 12/12] mkfs: replace variables with opts table: -r options Jan Tulak
2017-04-25 2:52 ` [PATCH 00/12] mkfs: save user input into opts table Luis R. Rodriguez
2017-04-25 16:20 ` Eric Sandeen
2017-04-26 2:02 ` Luis R. Rodriguez
2017-04-26 2:17 ` Eric Sandeen
2017-06-28 16:18 ` Luis R. Rodriguez
2017-06-29 7:56 ` Jan Tulak
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=20170425031326.GI28800@wotan.suse.de \
--to=mcgrof@kernel.org \
--cc=jtulak@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/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