Re: [PATCH] Preload infrastructure.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Tue, Oct 22, 2013 at 02:56:08PM +0000, Joseph S. Myers wrote:
> On Mon, 21 Oct 2013, Ondrej Bilka wrote:
> 
> > OK to commit?
> 
> Please don't ask that for something that is clearly nowhere near ready - 
> for example, doesn't integrate at all into the glibc build system, doesn't 

A purpose of initial patch is get framework on which we build. Insisting
on adding functionality only when it is perfect would cause harder
reviewing of incremental improvements as entire patch should be send,
making tracking of what is done harder.

> follow the GNU Coding Standards consistently, hardcodes "gcc" instead of 
> the appropriately configured compiler for the system for which glibc is 
> being built, 

a makefile is stub. If you want to improve in send a patch.

>hardcodes libc.so.6 rather than adapting for different SONAMEs on different targets, 

Elaborate.

> introduces an obvious security hole (and > code that won't work on multi-user systems) by hardcoding a path in /tmp, 

Elaborate why this is security hole.

> fails to use symbol versioning / otherwise ensure that the library only 
> exports the desired symbols and no others, 

This library is meant to be used by LD_PRELOAD, elaborate what problems do you
solve by versioning?

>isn't thread-safe (look at all 
> the use of static variables in strncat where the code could end up using 
> some variables from one thread and some from another),

That is heuristic to detect quadratic behaviour. For you I will change
writes to atomic writes and it will work as it is, in multithreaded case
worst that could happen is that log message will be printed twice.

> has no copyright /  license notices, is not documented in the glibc manual, ....

Could you remove directories benchtests and nptl. These are not
documented in manual and should be for such serious ommission deleted.

> 
> What you posted may be an early-stage example to inform discussion.  But 
> you need to write up a much more extended self-contained explanation of 
> the idea (but with references to prior art in this area), thinking
> carefully about the audiences for both that explanation and for the 
> library itself.  One obvious issue to consider is that some users may want 
> only diagnostics for invalid usages and not those for performance, or only 
> those for performance of particular functions and not others.
> 
Solved problem, when you do logging best way is write as much
information as possible. When users look for specific information they should 
learn to use grep.