[apparmor] [PATCH] parser: add basic support for parallel compiles and loads

John Johansen john.johansen at canonical.com
Sun Oct 25 06:51:55 UTC 2015

On 10/24/2015 06:05 AM, Christian Boltz wrote:
> Hello,
> Am Freitag, 23. Oktober 2015 schrieb John Johansen:
>> So one thing I wanted to ask here was whether or not we should default
>> this to --jobs=auto instead of 1
>> 1 is safe in that it is the current behavior, but I think we want this
>> on by default
> So we can choose between telling our users "add a parameter for better 
> performance" and "add a parameter if it breaks" ;-)
> I'd say the answer depends on the version number ;-)
> Also, how likely is it that something breaks?
> For  2.10.x, keeping the old behaviour as default will save us from an 
> angry mob if something breaks ;-) and for those who call the parser once 
> per profile, --jobs=auto doesn't bring any benefit.
> Therefore I tend to --jobs=1 as default in 2.10.x.
I hadn't really considered adding to 2.10. Its a new feature and we
generally try to avoid adding them to current releases

> Thinking about it - IIRC your code reduces the upper limit based on the 
> number of profiles specified as parameter, which means it will default 
> to --jobs=1 for "one parser call per profile" usecases anyway. So we 
No, it does the setup before determining if there is a single profile.
I could revise it to enable this.

> could take the risk to default to --jobs=auto even in 2.10.x, because in 
> most cases it will automatically "degrade" to --jobs=1.
well the way it is currently setup the worst case is a single extra
fork with --jobs=auto. However we could add detection to make this

> For 2.11, the answer is clear: --jobs=auto should be default.
I think so too, but I wanted to solicit other opinions

> We should also ship a service file that loads the whole /etc/apparmor.d/ 
> [1] with one parser call to avoid every distribution has to re-invent 
> the wheel ;-)
this is the goal, however while the parser can handle the load (start) and
remove (stop) cases. It can't currently provide restart, it can do the
replacement part, but won't the remove any profiles that were removed
from /etc/apparmor.d/ or any of the other dirs that could be passed.

I have a wip patch to provide restart, I was hoping to finish it this
weekend but that seems unlikely now.

> Regards,
> Christian Boltz
> [1] or even multiple (configurable) profile directories, as discussed on 
>     IRC some days ago. The configfile holding the paths should be in 
>     /etc/apparmor/ - /etc/sysconfig is nice, but specific to (open)SUSE 
>     AFAIK.

More information about the AppArmor mailing list