From: Michael Neuling <mikey@neuling.org>
To: "David N. Lombard" <dnlombar@ichips.intel.com>
Cc: Simon Horman <horms@verge.net.au>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
Matt Evans <matt@ozlabs.org>
Subject: Re: [RFC PATCH] kexec-tools: Fix option/argument parsing
Date: Sat, 15 May 2010 09:39:18 +1000 [thread overview]
Message-ID: <22330.1273880358@neuling.org> (raw)
In-Reply-To: <20100514133351.GA27254@nlxcldnl2.cl.intel.com>
In message <20100514133351.GA27254@nlxcldnl2.cl.intel.com> you wrote:
> On Thu, May 13, 2010 at 03:37:23PM -0700, Michael Neuling wrote:
> > In message <20100513144549.GB10534@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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2010-05-14 23:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-13 8:14 [RFC PATCH] kexec-tools: Fix option/argument parsing Matt Evans
2010-05-13 13:42 ` David N. Lombard
2010-05-13 14:45 ` Simon Horman
2010-05-13 22:37 ` Michael Neuling
2010-05-13 23:15 ` Matt Evans
2010-05-13 23:19 ` Michael Neuling
2010-05-14 13:33 ` David N. Lombard
2010-05-14 23:39 ` Michael Neuling [this message]
2010-05-13 23:22 ` Matt Evans
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=22330.1273880358@neuling.org \
--to=mikey@neuling.org \
--cc=dnlombar@ichips.intel.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=matt@ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox