OK to add _STRACE_FORK category?

[Christopher Faylor]

On Tue, May 10, 2011 at 09:32:17AM -0400, Ryan Johnson wrote:
>On 10/05/2011 6:09 AM, Corinna Vinschen wrote:
>> On May  4 15:33, Ryan Johnson wrote:
>>> Hi all,
>>>
>>> I'm currently producing sending quite a bit of information to
>>> special_printf while forking, and suspect that at least some of it
>>> would be good to leave in place. Further, I think it would make
>>> sense to have a fork category for strace so that people trying to
>>> diagnose fork problems have a way to figure out what's going wrong
>>> without having to slog through strace's all/debug output:
>>>
>>>          thread   0x040000 (_STRACE_THREAD)   Thread-locking calls.
>>> +       fork     0x080000 (_STRACE_FORK)     Fork-related information.
>>>          special  0x100000 (_STRACE_SPECIAL)  Special debugging printfs for
>>>                                               non-checked-in code
>>>
>>>
>>> If folks are all right seeing an _STRACE_FORK appear, I'll add that
>> I just noticed that I never replied.  Please use sigproc_printf and
>> debug_printf.  However, fork has already a lot of strace output, so
>> it would be favorable to keep the number of extra printfs as small
>> as possible.  Maybe there are even some we should remove.
>sigproc_printf: ack.
>
>As for the quantity of output, I'm torn. Whenever Windows throws a new 
>curveball at fork() the first step will always be to figure out what new 
>thing went wrong (or what existing thing is suddenly going wrong more 
>often), and I've added special_printf calls which expose this 
>information in a fair amount of detail. Problem is, AFAICT *_printf 
>calls execute fully whenever strace is active, with strace performing 
>the filtering on its side. This means a lot of unwanted overhead most of 
>the time. Perhaps I should leave the calls there, with an #ifdef 
>(DEBUGGING?) so future developers don't have to reinvent the wheel next 
>time around?

No.  You're basically asking for a special *_printf() function just for
yourself.  We don't want to litter fork with your debugging attempts.

cgf