[patch] Source entries removing is awfully slow.

[Gleb Smirnoff]

  Kajetan,

On Mon, Dec 02, 2013 at 05:28:57PM +0100, Kajetan Staszkiewicz wrote:
K> > On Sun, Dec 01, 2013 at 08:05:54PM +0100, Kajetan Staszkiewicz wrote:
K> > K> > Ok. Let's summurize what we need to:
K> > K> >
K> > K> > 1) Switch kill|reset, that affects both -K and -k.
K> > K> > 2) Add option to -K that would kill states.
K> > K> > 3) Add option to -K and -k to specify that argument is a table.
K> > K> > 4) Try not to add new global option keys.
K> > K> >
K> > K> > What we got:
K> > K> >
K> > K> > 1) -k supports specifying that argument is label or id. This is done
K> > via K> > multiple -k specifiers:
K> > K> >
K> > K> >    pfctl -k id -k 4823e84500000003
K> > K> >
K> > K> > 2) -K and -k can be specified twice, meaning -k source -K destination.
K> > K> >
K> > K> > So, 1) and 2) make order of multiple arguments important.
K> > K> >
K> > K> > The main problem is that we need to keep working current syntax, which
K> > I K> > find ugly. The biggest problem is that order of arguments matters.
K> > This is K> > really a bad habbit.
K> > K> >
K> > K> > What about if we come with something order-agnostic as alternative to
K> > K> > current syntax? And put all enhanced state/srcnode killing/resetting
K> > into K> > this new syntax, w/o touching current syntax. The current syntax
K> > will be K> > mark as obsoleted in manual page. We might even want to
K> > implement all K> > these new features in a new utility. Not sure there is
K> > a reason to do, so K> > but is possible.
K> > K>
K> > K> I believe it is possible to extend the current syntax without breaking
K> > K> compatibility. Have a look:
K> > K> - A list of -K string1 -K string2... is provided.
K> > K> - Magic keywords are: label, id, table, rdrhost, kill ("states",
K> > K>   "rststates").
K> > K> - If there is a magic keyword at any position, the next position is a
K> > value for K>   the keyword.
K> > K> - If there is a string, which is not a magic keyword, at any position,
K> > it is K>   src host or dst host, depending on position (first is src, next
K> > is dst). K> - Of course not all keywords apply both to -K and -k (e.g
K> > state's rdrhost is K>   src_node's dst).
K> > K>
K> > K> This is:
K> > K> - Compatible with the current syntax.
K> > K> - Extends the syntax to my needs.
K> > K> - By coincidence extedns the syntax for matching by multiple keywords +
K> > src/dst K>   at once. Kernel should already handle that, pfctl.c needs to
K> > be changed. K>
K> > K> It can be extended with more magic keywords: srchost, dsthost. This
K> > would make K> order of tuples (-K keyword -K value) fully obsolete.
K> > K>
K> > K> How do you find the idea?
K> > 
K> > Well, that would work. I just dislike the current syntax order dependant:
K> > 
K> > '-K foo -K bar' isn't equal to '-K bar -K foo'
K> > 
K> > But compatibility issue can overweight saneness.
K> 
K> Do we have an agreement then? Shall I start developing this?

I won't object on any interface that is consistent and resides in the
'-K' and '-k' namespace. As said before, I am against utilizing new
letters for options to avoid clashing with pfctl syntax in OpenBSD.

Thank you.

-- 
Totus tuus, Glebius.