[RFC PATCH] kexec-tools: Fix option/argument parsing
David N. Lombard
dnlombar at ichips.intel.com
Fri May 14 09:33:51 EDT 2010
On Thu, May 13, 2010 at 03:37:23PM -0700, Michael Neuling wrote:
> In message <20100513144549.GB10534 at verge.net.au> you wrote:
> > On Thu, May 13, 2010 at 06:14:32PM +1000, Matt Evans wrote:
> > >
> > > In playing with kexec-tools I've noticed various problems with the argument
> > > passing, meaning one has to be careful to use certain forms of arguments
> > > and present them in a certain order.
> > >
[deletia]
> > >
> > > This behaviour is avoided by using the --opt= forms, but getopt does allow
> > > both and hence the user can have a fairly frustrating experience. (Doing
> > > something unexpected (ex. 3) is more annoying than an error exit (ex. 1)
> > > in many cases.)
> > >
> >
> > This seems reasonable to me.
> >
> > I've compiled tested the code on all architectures except cris (I don't
> > have my build environment at the moment). I found a minor problem on arm
> > which I have noted below.
>
> I suspect it'll break someones kexec scripts, so maybe we take this
> patch (or something like it) but bump up the release revision to 2.1?
>
How?
Command lines that previously worked will continue to work.
Command lines that should have worked, but didn't, will now work.
Command lines that shouldn't have worked will still not work.
The only scripts that may fail are those doing negative testing to check for
a form that *should* have been allowed--quite clearly, any such negative testing
was incorrect.
--
David N. Lombard, Intel, Irvine, CA
I do not speak for Intel Corporation; all comments are strictly my own.
More information about the kexec
mailing list