| Message ID | 20210210165407.9770-1-dwagner@suse.de |
|---|---|
| Headers | show |
| Series | oslat fixes | expand |
On Wed, 10 Feb 2021, Daniel Wagner wrote: > During the streamlining of the command line options we missed to hook > up the command line option '--version' with usage(). > > Fixes: e411219d27b1 ("oslat: Streamline usage output and man page") > Reported-by: Peter Xu <peterx@redhat.com> > Signed-off-by: Daniel Wagner <dwagner@suse.de> > --- > src/oslat/oslat.c | 8 +------- > 1 file changed, 1 insertion(+), 7 deletions(-) > > diff --git a/src/oslat/oslat.c b/src/oslat/oslat.c > index 5b7e0d5b5d5c..d3f659b218b0 100644 > --- a/src/oslat/oslat.c > +++ b/src/oslat/oslat.c > @@ -655,16 +655,10 @@ static void parse_options(int argc, char *argv[]) > */ > g.single_preheat_thread = true; > break; > - case 'v': > - /* > - * Because we always dump the version even before parsing options, > - * what we need to do is to quit.. > - */ > - exit(0); > - break; > case 'z': > g.output_omit_zero_buckets = 1; > break; > + case 'v': > case 'h': > usage(0); > break; > -- > 2.30.0 > > It shouldn't be a fall through, we don't want to print the usage.
On Wed, Feb 10, 2021 at 06:33:53PM +0100, Daniel Wagner wrote: > On Wed, Feb 10, 2021 at 12:28:09PM -0500, John Kacur wrote: > > It shouldn't be a fall through, we don't want to print the usage. > > Ok. In this case I suggest we introduce for all tolls the long option > '--version' and print only the version string. > > As I have already added the long parsing option in my series 'Generate > machine-readable output'. This was a lot of tedious work, so I would > like to avoid to do it split out for the '--version' option. Thus, could > you review the series and I could easily fix this problem. It's great idea to have JSON format for all the tools. However I just don't see why "-v"/"--version" is related to your machine readable output work. Could you exlaborate? Thanks,
> It's great idea to have JSON format for all the tools. However I just don't > see why "-v"/"--version" is related to your machine readable output work. > Could you exlaborate? Thanks, I've added long options support to many rt-tests in the mentioned series. I would like to base this fix on top of this work.
On Wed, 10 Feb 2021, Daniel Wagner wrote: > On Wed, Feb 10, 2021 at 12:59:29PM -0500, John Kacur wrote: > > Are you really telling me you won't fix a problem you introduced unless > > I first take all the other code you would like to get in rt-tests? > > I've already done the long option support in the JSON series. It would > make my life way simpler if those bits would be in the tree. > > I think, the simplest fix for now is to temporarily a local fix for > oslat. > Just add a fix onto for the oslat problem on the end of your series I'll be done the review soon. If we need to do any backporting then we'll do that. Cheers, Thanks John
On Wed, 10 Feb 2021, John Kacur wrote: > > > On Wed, 10 Feb 2021, Daniel Wagner wrote: > > > On Wed, Feb 10, 2021 at 12:59:29PM -0500, John Kacur wrote: > > > Are you really telling me you won't fix a problem you introduced unless > > > I first take all the other code you would like to get in rt-tests? > > > > I've already done the long option support in the JSON series. It would > > make my life way simpler if those bits would be in the tree. > > > > I think, the simplest fix for now is to temporarily a local fix for > > oslat. > > > > Just add a fix onto for the oslat problem on the end of your series > I'll be done the review soon. > > If we need to do any backporting then we'll do that. > > Cheers, Thanks > > John > I rewound your patches in git, and applied the two oslat fixes and reapplied your patches with a git interactive rebase, and then I pushed them for others to try before I'm ready to push them upstream Anyone who wants to try the new json stuff it's in a branch called unstable/devel/rt-numa-json The numa changes need more testing before integrate them, but this should make it easier for others to try it out. John