On Tue, Mar 24, 2020 at 03:57:26PM -0500, Eric Sandeen wrote: > On 3/23/20 7:19 PM, Dave Chinner wrote: > > From: Dave Chinner <dchinner@xxxxxxxxxx> > > > > Many operations don't set the exitcode when they fail, resulting > > in xfs_io exiting with a zero (no failure) exit code despite the > > command failing and returning an error. The command return code is > > really a boolean to tell the libxcmd command loop whether to > > continue processing or not, while exitcode is the actual xfs_io exit > > code returned to the parent on exit. > > > > This patchset just makes the code do the right thing. It's not the > > nicest code, but it's a start at producing correct behaviour. > > > > Signed-Off-By: Dave Chinner <dchinner@xxxxxxxxxx> > > I wonder if there somewhere we could formally document these conventions... > > Like maybe at least near the "exitcode" global declaration? I really think we need to rework the way we do the error handling in the command line parsing for these utilities. One of the things I found in doing this is that most of the code does return error codes to the main function, only then to drop it on the floor and turn it into "exitcode = 1; return 0;" pair. So I'm pondering how to make this much simpler - returning error codes from the command functions would be a much better idea, then have a command flag to indicate whether we continue on error or terminate. That moves all the exit code handling out of the commands and provides consistent error handling for all commands and infrastructure - 0 = success, failure returns negative errno - and so should enable much more reliable and consistent error handling across all the utilities.... Thoughts? Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
