Comment 9 for bug 1438249

So just a little more context around this whole split in policy loading. AppArmor does a check that the cached policy is current and matches to the kernel before loading and then if not falls back to recompiling policy. The policy load was split into an early stage (/etc/apparmor/init) and full policy (/etc/apparmor.d/), so that early boot would only load the minimum amount of policy needed during early boot to minimize potential delays (specifically fallback to compile) during early boot. The recompile is not such an issue in later boot as it can be run in parallel with more services.

TLDR: The split is all about boot speed. It would be easier and safer if all policy was loaded as early as possible.

More context:
* apparmor init scripts all sys V and not upstart based (for various reasons)
* apparmor_parser at the time would only process one file and had to be called multiple times (which slowed down loading) - (FIXED)
* apparmor_parser is single threaded, so shell scripts were used to get parallel loading/compiles - (NOT fixed)
* apparmor_parser was a LOT (at least a couple orders of magnitude) slower at compiles when this was done
* apparmor_parser couldn't properly build policy for anything but the current kernel, so policy compile was always left to first boot of a given kernel
  - specifying the feature set was broken (FIXED)
  - the abi matching had issues (FIXED)
  - new kernels didn't ship the needed feature information to compile policy for the kernel during kernel installed so policy compiles needed to wait until booting into the new kernel (NOT fixed)
* apparmor only supported a single cache ( NOT fixed - soon)
  - needed to support policy for multiple kernels, having policy compiled before boot.