[RFC PATCH] kexec-tools: Fix option/argument parsing

[Michael Neuling]

In message <20100514133351.GA27254 at nlxcldnl2.cl.intel.com> you wrote:
> 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 argu
ment
> > > > passing, meaning one has to be careful to use certain forms of argument
s
> > > > and present them in a certain order.
> > > > 
> [deletia]
> > > > 
> > > > This behaviour is avoided by using the --opt= forms, but getopt does al
low
> > > > both and hence the user can have a fairly frustrating experience.  (Doi
ng
> > > > 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.

Yeah, and like I said, users are pretty dumb, so put 1 and 1
together... :-)

That being said, I don't have a strong opinion.  If others think it's
unlikely enough that anyone will hit it, then let's keep the release
numbering as it is.

... and I think we all agree we need the patch. 

Mikey