Hi Martin,
Martin Pitt wrote (03 May 2015 08:36:40 GMT) :
> Could we change the scripts to drop xargs? I. e replace constructions
> like "cmd1 | xargs -n1 cmd2" with "for i in `cmd1`; do cmd2 $i; done",
> or "cmd1 | xargs cmd2" with "cmd2 `cmd1`"?
I see xargs used for a few different purposes in
debian/lib/apparmor/functions:
* when compiling the policy from scratch, e.g. on Live systems:
with -n1 -P, so that all CPU cores are used; in this case, simply
dropping xargs would imply a significant boot time increase for SMP
systems that have no cache. E.g. on my Tails/Jessie VM, the apparmor
service startup takes 13s with one single core, and 7s with two
cores (note that we've removed the $remote_fs dependency a while ago
in Tails/Jessie already). I'd rather avoid taking that performance
hit, and I can think of two potential solutions:
- long-term: Live systems should ship a cached pre-compiled policy,
as is done for the Ubuntu phone. My understanding is that this
requires the ISO build system to run the exact same kernel as the
one shipped inside the ISO, which is quite impractical.
- short-term: instead of "xargs -n1 -P", we could use busybox'
xargs; it doesn't support -P, so we need to manually compute the
optimal -n parameter (number of profiles / number of CPU cores).
Thoughts, opinions, patches? :)
* when refreshing the policy cache: with -P only, so likely only one
apparmor_parser is run, and then dropping xargs shouldn't change
anything.
* in clear_cache(), that's used by the init script's start action when
the policy was updated. Here, we could indeed call "rm $(...)"
instead, but then we would lose the benefits from the nice
"find -print0 | xargs -0" pattern. OTOH, the cache directories are
only writable by root, so in this case it should be safe to simply
use "rm $(...)".
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
