Skip to content
  • Eric Blake's avatar
    64ebf556
    qemu-io: Don't die on second open · 64ebf556
    Eric Blake authored
    
    
    Most callback commands in qemu-io return 0 to keep the interpreter
    loop running, or 1 to quit immediately.  However, open_f() just
    passed through the return value of openfile(), which has different
    semantics of returning 0 if a file was opened, or 1 on any failure.
    
    As a result of mixing the return semantics, we are forcing the
    qemu-io interpreter to exit early on any failures, which is rather
    annoying when some of the failures are obviously trying to give
    the user a hint of how to proceed (if we didn't then kill qemu-io
    out from under the user's feet):
    
    $ qemu-io
    qemu-io> open foo
    qemu-io> open foo
    file open already, try 'help close'
    $ echo $?
    0
    
    In general, we WANT openfile() to report failures, since it is the
    function used in the form 'qemu-io -c "$something" no_such_file'
    for performing one or more -c options on a single file, and it is
    not worth attempting $something if the file itself cannot be opened.
    So the solution is to fix open_f() to always return 0 (when we are
    in interactive mode, even failure to open should not end the
    session), and save the return value of openfile() for command line
    use in main().
    
    Note, however, that we do have some qemu-iotests that do 'qemu-io
    -c "open file" -c "$something"'; such tests will now proceed to
    attempt $something whether or not the open succeeded, the same way
    as if the two commands had been attempted in interactive mode.  As
    such, the expected output for those tests has to be modified.  But it
    also means that it is now possible to use -c close and have a single
    qemu-io command line operate on more than one file even without
    using interactive mode.  Although the '-c open' action is a subtle
    change in behavior, remember that qemu-io is for debugging purposes,
    so as long as it serves the needs of qemu-iotests while still being
    reasonable for interactive use, it should not be a problem that we
    are changing tests to the new behavior.
    
    This has been awkward since at least as far back as commit
    e3aff4f6, in 2009.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarFam Zheng <famz@redhat.com>
    Reviewed-by: default avatarJohn Snow <jsnow@redhat.com>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    64ebf556
    qemu-io: Don't die on second open
    Eric Blake authored
    
    
    Most callback commands in qemu-io return 0 to keep the interpreter
    loop running, or 1 to quit immediately.  However, open_f() just
    passed through the return value of openfile(), which has different
    semantics of returning 0 if a file was opened, or 1 on any failure.
    
    As a result of mixing the return semantics, we are forcing the
    qemu-io interpreter to exit early on any failures, which is rather
    annoying when some of the failures are obviously trying to give
    the user a hint of how to proceed (if we didn't then kill qemu-io
    out from under the user's feet):
    
    $ qemu-io
    qemu-io> open foo
    qemu-io> open foo
    file open already, try 'help close'
    $ echo $?
    0
    
    In general, we WANT openfile() to report failures, since it is the
    function used in the form 'qemu-io -c "$something" no_such_file'
    for performing one or more -c options on a single file, and it is
    not worth attempting $something if the file itself cannot be opened.
    So the solution is to fix open_f() to always return 0 (when we are
    in interactive mode, even failure to open should not end the
    session), and save the return value of openfile() for command line
    use in main().
    
    Note, however, that we do have some qemu-iotests that do 'qemu-io
    -c "open file" -c "$something"'; such tests will now proceed to
    attempt $something whether or not the open succeeded, the same way
    as if the two commands had been attempted in interactive mode.  As
    such, the expected output for those tests has to be modified.  But it
    also means that it is now possible to use -c close and have a single
    qemu-io command line operate on more than one file even without
    using interactive mode.  Although the '-c open' action is a subtle
    change in behavior, remember that qemu-io is for debugging purposes,
    so as long as it serves the needs of qemu-iotests while still being
    reasonable for interactive use, it should not be a problem that we
    are changing tests to the new behavior.
    
    This has been awkward since at least as far back as commit
    e3aff4f6, in 2009.
    
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarFam Zheng <famz@redhat.com>
    Reviewed-by: default avatarJohn Snow <jsnow@redhat.com>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Loading