Re: [PATCH rt-tests v2 04/14] rt-util: Copy command line before getopt_long() is called

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Mon, 15 Mar 2021, Daniel Wagner wrote:

> On Mon, Mar 15, 2021 at 01:47:22AM -0400, John Kacur wrote:
> > 
> > 
> > On Fri, 5 Mar 2021, Daniel Wagner wrote:
> > 
> > > By default, getopt_long() permutes the contents of argv as it scans,
> > > so that eventually all the nonoptions are at the end. This is
> > > confusing in the JSON output, thus copy the command line before we
> > > call getopt_long().
> > > 
> > > Introduce a rt_init() which copies the command line. This makes also
> > > rt_write_json() function arguments a bit cleaner.
> > > 
> > > Signed-off-by: Daniel Wagner <dwagner@xxxxxxx>
> > > ---
> > >  src/cyclictest/cyclictest.c           |  3 +-
> > >  src/include/rt-utils.h                |  7 +++--
> > >  src/lib/rt-utils.c                    | 45 ++++++++++++---------------
> > >  src/oslat/oslat.c                     |  5 +--
> > >  src/pmqtest/pmqtest.c                 |  3 +-
> > >  src/ptsematest/ptsematest.c           |  3 +-
> > >  src/rt-migrate-test/rt-migrate-test.c |  3 +-
> > >  src/sched_deadline/cyclicdeadline.c   |  4 ++-
> > >  src/signaltest/signaltest.c           |  3 +-
> > >  src/sigwaittest/sigwaittest.c         |  3 +-
> > >  src/svsematest/svsematest.c           |  3 +-
> > >  11 files changed, 44 insertions(+), 38 deletions(-)
> > > 
> > > diff --git a/src/cyclictest/cyclictest.c b/src/cyclictest/cyclictest.c
> > > index c43dd7cbbd64..3f3b91bab53b 100644
> > > --- a/src/cyclictest/cyclictest.c
> > > +++ b/src/cyclictest/cyclictest.c
> > > @@ -1778,6 +1778,7 @@ int main(int argc, char **argv)
> > >  	int i, ret = -1;
> > >  	int status;
> > >  
> > > +	rt_init(argc, argv);
> > 
> > Why should we call this if we're not using formatted output?
> 
> Yes unfortunately. We only know after we used getopt_long() that we should
> have stored argv, kind of chicken-egg situation.
> 

One more thing, could you please break your patches up into smaller more
manageable sizes?
I would put for example changes to rt-utils in one patch

It might be a pain to then create a separate patch for each test to 
interact with it, but imagine that we get the situation where the changes
don't work well with a particular test, I'd rather just revert the one 
test that revert everything.

Thanks

John



[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux