On Tue, Apr 06, 2021 at 08:51:30PM +0930, Simon Lees wrote: > > > On 4/6/21 7:22 PM, Pablo Neira Ayuso wrote: > > 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? > > We had a customer complaining about the change in ordering causing > different results with one way working and the other not, looking back > at the report a second time I don't think they were ever using the "non > working way" in production but just to debug the other issue. Thanks for explaining, then I think we can go for the "restrict position" fix which aligns with the -M, -t, ..., correct?
Attachment:
signature.asc
Description: PGP signature
