Re: [PATCH 1/2] ebtables: processing '--concurrent' beofore other arguments

[Pablo Neira Ayuso <pablo@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]

Hi,

On Tue, Apr 06, 2021 at 05:29:11PM +0930, Simon Lees wrote:
> 
> 
> On 4/6/21 12:27 PM, Firo Yang wrote:
> > The 04/03/2021 20:22, Pablo Neira Ayuso wrote:
> >> On Sat, Apr 03, 2021 at 08:15:17PM +0200, Pablo Neira Ayuso wrote:
> >>> Hi,
> >>>
> >>> On Thu, Apr 01, 2021 at 12:07:40PM +0800, Firo Yang wrote:
> >>>> Our customer reported a following issue:
> >>>> If '--concurrent' was passed to ebtables command behind other arguments,
> >>>> '--concurrent' will not take effect sometimes; for a simple example,
> >>>> ebtables -L --concurrent. This is becuase the handling of '--concurrent'
> >>>> is implemented in a passing-order-dependent way.
> >>>>
> >>>> So we can fix this problem by processing it before other arguments.
> >>>
> >>> Would you instead make a patch to spew an error if --concurrent is the
> >>> first argument?
> >>
> >> Wrong wording:
> >>
> >> Would you instead make a patch to spew an error if --concurrent is
> >> _not_ the first argument?
> > 
> > Hi Pablo, I think it would make more sense if we don't introduce this
> > inconvenice to users. If you insist, I would go create the patch as you
> > intended.
> 
> Agreed, that also wouldn't be seen as a workable solution for us "SUSE"
> as our customers who may have scripts or documented processes where
> --concurrent is not first and such a change would be considered a
> "Change in behavior" as such we can't ship it in a bugfix or minor
> version update, only in the next major update and we don't know when
> that will be yet.
>
> Sure this is probably only a issue for enterprise distro's but such a
> change would likely inconvenience other users as well.

--concurrent has never worked away from the early positions ever.

What's the issue?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]