The 04/06/2021 13:31, Pablo Neira Ayuso wrote: > 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? Hi Pablo, To be frank, I think the 'restrict position' manner is really unfriendly to users, which put burden on them to learn and remember this kind of rare and unique usage. I could create a bigger patch to change other arugments '-M', '-t' along with '--concurrent'. Does this sound good to you? -- Firo
