[Ltrace-devel] [PATCH RESEND] Add POSIX Threads prototypes

Petr Machata pmachata at redhat.com
Mon Mar 16 10:07:48 UTC 2015


Роман Донченко <dpb at corrigendum.ru> writes:

> Petr Machata <pmachata at redhat.com> писал в своём письме Thu, 12 Mar
> 2015 00:25:36 +0300:
>
>> Also, you don't want to simply call read_config_file recursively, as
>> that would re-read the file every time it's included.  You also still
>> want to allow the full suite of overrides that ltrace admits,
>> i.e. looking through XDG_CONFIG_DIRS et.al.
>
> I don't think I do, actually! If we do that, then the includer is
> never going to know what it's including. I.e., if a.conf includes
> b.conf, and b.conf is overridden, then the override might not contain
> the stuff that a.conf depends on, so it'll be broken. I think we
> should only search in a.conf's directory in this case.

That's a good point, I didn't think about it this way.

But ultimately my opinion is that it's desirable to allow users to
override this stuff.  As long as they include all the necessary
interfaces, they are fine, and they can correct mistakes, add omissions,
etc.

More importantly, this allows users to reuse the type libraries.  Any
library could do something like "import libc.so-types".  That would look
up libc.so-types in /usr/share even if your library is e.g. in your home
directory as you work on it, and you could use things like FILE* etc.

(One particularly useful thing to have would be something like "import
next", which would work similarly to RTLD_NEXT in dlopen.  It would
allow users to add bits and pieces to the system config file.  But
that's tangential to the orginial point.)

>> The right way about it is to go through protolib cache, which handles
>> all this stuff.  So read_config_file would need to get an argument of
>> the type struct protolib_cache *.  An include line would trigger a call
>> to protolib_cache_load.  The result would be added to the currently
>> loaded protolib by protolib_add_import.
>
> Hmm... I don't really want to include complete protolibs into other
> protolibs, though. Okay, for libc.so.conf and libpthread.so.conf I do,
> but that's an exception, not the rule. For the general case, I
> envision a C-like structure, where there are "header files" with
> common type definitions, but which aren't necessarily complete
> protolibs themselves. Like this:
>
> types.inc:
> typedef ldouble = double;

This is a complete protolib that contains one typedef.  That's fine.

> Now, I suppose, we could require the header files to be valid config
> files in themselves (types.inc is), and then we could store them as
> protolibs in the cache, but honestly, I don't see much point in
> that. They're going to be parsed at most once per library, which I
> don't think is a big deal, and if we do cache them, they'll just stay
> in the cache after all the library configs have been parsed, serving
> no purpose.

They could be parsed once per library load, or they could be parsed once
and then looked up.  Protolib cache is simply a work-saving mechanism.
Since this stuff is immutable, there's no reason to parse it repeatedly.

Thanks,
Petr



More information about the Ltrace-devel mailing list