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

[Роман Донченко]

Petr Machata <pmachata at redhat.com> писал в своём письме Mon, 16 Mar 2015  
13:07:48 +0300:

> Роман Донченко <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.

Yeah, okay, makes sense.

>>> 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.

Sure, sure. If we're going to do the override search, then using the cache  
is easier than not using it, anyway.

Alright, I'll see if I can hack something up in my copious free time.

Roman.