diff mbox

xfs_io: support -c <cmd> without <file> args

Message ID 1480921485-14888-1-git-send-email-amir73il@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Amir Goldstein Dec. 5, 2016, 7:04 a.m. UTC
There is an undocumented and possibly unused feature in xfs_io
where all commands are executed per file given in the file args list.

This feature creates ambiguity when trying to execute commands
such as "open" and "file" from command line.

When running xfs_io -c <cmd> without any file args, xfs_io exits
without doing anything. This behavior is undocumented and does not
make much sense either.

Change the behavior in the case where no file args are given in
command line to execute every command exactly once, exactly as if
the commands where executed from an interactive shell.

This enables writing proper xfs_io scripts in command line, which
include "open" and "file" commands.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 io/init.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

Comments

Dave Chinner Dec. 5, 2016, 11:02 a.m. UTC | #1
On Mon, Dec 05, 2016 at 09:04:45AM +0200, Amir Goldstein wrote:
> There is an undocumented and possibly unused feature in xfs_io
> where all commands are executed per file given in the file args list.
> 
> This feature creates ambiguity when trying to execute commands
> such as "open" and "file" from command line.
> 
> When running xfs_io -c <cmd> without any file args, xfs_io exits
> without doing anything. This behavior is undocumented and does not
> make much sense either.
> 
> Change the behavior in the case where no file args are given in
> command line to execute every command exactly once, exactly as if
> the commands where executed from an interactive shell.
> 
> This enables writing proper xfs_io scripts in command line, which
> include "open" and "file" commands.

NACK.

This does not fix any of the underlying problems. It just adds
another WTF case to CLI processing as two things that should be
equivlent now behave differently. i.e.

$ xfs_io -c "open foo" -c "open bar" -c file

and 

$ xfs_io -c "open bar" -c file foo

will have different behaviour, even though the man page says they
should be equivalent and do exactly the same thing.

Fix the underlying problems once and for all: do not hack bandaids
into the code that only hides the symptom for your specific use
case.

-Dave.
Amir Goldstein Dec. 5, 2016, 11:27 a.m. UTC | #2
On Mon, Dec 5, 2016 at 1:02 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Mon, Dec 05, 2016 at 09:04:45AM +0200, Amir Goldstein wrote:
>> There is an undocumented and possibly unused feature in xfs_io
>> where all commands are executed per file given in the file args list.
>>
>> This feature creates ambiguity when trying to execute commands
>> such as "open" and "file" from command line.
>>
>> When running xfs_io -c <cmd> without any file args, xfs_io exits
>> without doing anything. This behavior is undocumented and does not
>> make much sense either.
>>
>> Change the behavior in the case where no file args are given in
>> command line to execute every command exactly once, exactly as if
>> the commands where executed from an interactive shell.
>>
>> This enables writing proper xfs_io scripts in command line, which
>> include "open" and "file" commands.
>
> NACK.
>
> This does not fix any of the underlying problems. It just adds
> another WTF case to CLI processing as two things that should be
> equivlent now behave differently. i.e.
>
> $ xfs_io -c "open foo" -c "open bar" -c file
>

You meant:
$ xfs_io -c "open foo" -c "open bar"

> and
>
> $ xfs_io -c "open bar" -c file foo
>
> will have different behaviour, even though the man page says they
> should be equivalent and do exactly the same thing.
>
> Fix the underlying problems once and for all: do not hack bandaids
> into the code that only hides the symptom for your specific use
> case.
>

Dave,

I would be glad to fix the code, but you did not answer my question.

The "execute all commands per file" behavior is not documented,
does not appear to have any known users and makes every attempt
to parse "file" commands ambiguous.

Can we, in your option, do away with this behavior?

If the answer is yes, then the patch is even simpler then these 16 lines.
Just replace the old init_args_command() with the new
do_once_args_command().

Would you like me to re-submit the patch with this change?

Amir.
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/io/init.c b/io/init.c
index a9191cf..785eb05 100644
--- a/io/init.c
+++ b/io/init.c
@@ -91,7 +91,7 @@  init_commands(void)
 }
 
 static int
-init_args_command(
+per_file_args_command(
 	int	index)
 {
 	if (index >= filecount)
@@ -101,6 +101,13 @@  init_args_command(
 }
 
 static int
+do_once_args_command(
+	int	index)
+{
+	return !index;
+}
+
+static int
 init_check_command(
 	const cmdinfo_t	*ct)
 {
@@ -214,7 +221,12 @@  init(
 	}
 
 	init_commands();
-	add_args_command(init_args_command);
+	/*
+	 * If file args exist, execute all commands for every file.
+	 * Otherwise, execute every command once exactly as in interactive mode.
+	 */
+	add_args_command(filecount ? per_file_args_command :
+			 do_once_args_command);
 	add_check_command(init_check_command);
 }