On 12/28/2011 03:28 PM, Seth Arnold wrote:
yes it would be, whether we want to change this, so that abstractions can
end their file on the same line as a MODE I am unsure.
It's a definite corner case -- not too many people are going to be using
echo -n to append lines to abstractions...
yeah, atm its one I am willing to break, I think
For various reasons I favor not having the include be just a text dump,
but perhaps that isn't what other people want.
I've still got a moderate hope that we can improve parsing speeds for some
of our long run times by scanning each included file at most once --
though the variables definitely complicate this.
Well yes we certainly will, but at what level is still an open question.
Eg. Currently includes are just pulled in, resulting in a lot of duplicate
rules which we rely on tree factoring to partly undo.
We can and will get this earlier once I get the parser context patches done.
That way within a given profile we will only have to parse and compile an
include once. This will reduce a lot of the current duplication, reducing
the need for the duplicate elimination pass, reducing the work in tree
factoring and possibly also the amount of redundant states that need to
be eliminated in minimization.
As to whether we will get to using includes as precompiled chunks I am unsure.
They need to be larger enough that it will be worth it. Basically with out
playing
more with it I am unsure that includes are the right boundry for determining
precompiled chunks
Also, be very careful with the variable-length trailing context: flex
runtime goes to hell in a hurry when trailing context isn't a fixed, known
length: http://flex.sourceforge.net/manual/Performance.html
yes, but this case is a fixed length with a fixed number of characters.
It _looks_ that way, but I think flex is being annoying here:
For some trailing context rules, parts which are actually fixed-length
are not recognized as such, leading to the abovementioned performance
loss. In particular, parts using '|' or {n} (such as "foo{3}") are
always considered variable-length.
I think /[[:blank:]\n,] would be sufficient to replace the three
alternating rules. It's unfortunate that this duplicates all three
patterns but it does remove the alternation.
hrmmm, I will have to try that, we should be able to see a difference in the
flex
state dump
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
