On Tue, 2005-11-29 at 09:43 -0800, Tom London wrote:
> On 11/29/05, Ivan Gyurdiev <ivg2@xxxxxxxxxxx> wrote:
> >
> > > Quite the difference, no?
> > >
> > Maybe this could be generalized (what's special about /dev?).
> > "make install" does not need to analyze all the paths on the system
> > (per file!)...
> >
> Hmm....
>
> This sort of suggests a different file organization, no?
>
> How about 'overlaying' something like a trie or some search tree
> organized by directory 'prefixes' (e.g., '/dev', '/lib', etc.). Should
> be possible to organize the general matching cases into one bucket.
IIUC, the primary overhead isn't during the matching phase; it is during
initial processing of file_contexts by matchpathcon_init(), when it
loads the entire file_contexts configuration into the in-memory
representation and compiles all of the regexes. Most of the time is
spent in regcomp(). So the only way to reduce it is to reduce the set
of entries processed during matchpathcon_init(), which doesn't know what
paths you are going to subsequently try matching via matchpathcon().
The expected usage model was that matchpathcon_init() would be invoked
once followed by multiple matchpathcon() calls by the application, as in
setfiles and restorecon (the original users). IIUC, udev is executed on
each event, so it ends up performing matchpathcon_init() on every node
creation and we don't get any caching of the data.
We could introduce a variant interface that is optimized for the case
where you are only going to perform matchpathcon() calls on paths with a
common prefix (e.g. /dev), or the SELinux support in udev could be
re-visited (leveraging the udevd daemon to cache the data once for all
udev instances?).
--
Stephen Smalley
National Security Agency
|
