[Ltrace-devel] [PATCH 2/2] configuration: added 'include' statement

Petr Machata pmachata at redhat.com
Mon Sep 16 21:26:14 UTC 2013


Enrico Scholz <enrico.scholz at sigma-chemnitz.de> writes:

> Patch adds an 'include' statement which can be used to include other

I do agree an include mechanism is necessary, but I envision something a
bit different than you.

> configuration files recursively.  This makes it e.g. possible for
> linux distributions to add
>
> | include /etc/ltrace.conf.d/*.conf
>
> to /etc/ltrace.conf and ship ltrace definitions in dedicated files
> like '/etc/ltrace.conf.d/mylib.conf'.

This should not be necessary.  When a library is mapped in, ltrace looks
for <soname>.conf in /etc/ltrace/ (among others--it also honors
XDG_CONFIG_HOME and XDG_CONFIG_DIRS, and looks into directories passed
in -F).

The above approach is also bound to cause problems in case of symbol
name clashes.  ltrace handles this by creating a separate protolib for
each process group, and adding imports to it as DSO's are mapped in.
Thus name clashes only occur if they also occur in ELF symbol tables.

I'm not convinced that there's a need to support glob includes at all.

Your include mechanism also copies symbols from the included file,
meaning if several protolibs include the same file (e.g. libc types such
as FILE, sigset, etc. should be in a separate file for easy reuse),
those copies are not shared, and the include file is reread each time
it's included.

ltrace already has a mechanism for imports and caching.  The way I
imagine this is that the user would write, e.g.:

	include mylib-common

And in read_config_file, ltrace would do something like:

	struct protolib *include
		= protolib_cache_search(cache, "mylib-common", 0, 1);
	if (include == NULL || protolib_add_import(plib, include) < 0)
		/* Handle errors.  */

protolib_cache_search knows to look for mylib-common.conf in the usual
places--in directories passed in -F, the XDG stuff, etc.

This would need some way of detecting recursive includes.  There is
logic for detecting mutual imports in protolib_add_import, but that's
too late--we need to detect it probably in protolib_cache_file, as that
recursively calls read_config_file.  The immediate idea is that
protolib_cache_file immediately caches a pseudo-library that denotes
that given cache entry is under construction, and when the loading is
done, it overwrites that pseudo library with the actual thing.

If we have such mutual-include guard, I belive that the MAX_DEPTH check
can go away.  So what if the user wants to construct a crazy 100-deep
hierarchy of ltrace config files.

Opinions?  If you are still interested in working on this, I'd gladly
accept a patch that implements the above (or whatever comes out of the
ensuing discussion).

Thank you,
PM



More information about the Ltrace-devel mailing list