# Re: \[PATCH\] tr2: log parent process name

- From: Jeff Hostetler \<hidden\>
- Date: 2021-05-11 17:28:41 
- List: git
- Page: https://ratatoskr.run/git/2021/05/7887465
- Thread: https://ratatoskr.run/git/2021/05/7887151/t.md

```text


On 5/6/21 8:29 PM, Emily Shaffer wrote:
> It can be useful to tell who invoked Git - was it invoked manually by a
> user via CLI or script? By an IDE? Knowing where the Git invocation came
> from can help with debugging to isolate where the problem came from.
>
> Unfortunately, there's no cross-platform reliable way to gather the name
> of the parent process. If procfs is present, we can use that; otherwise
> we will need to discover the name another way. However, the process ID
> should be sufficient regardless of platform.
>
> Signed-off-by: Emily Shaffer <redacted>
> ---
> We briefly discussed hiding this behind a config, internally. However, I
> wanted to include the parent name alongside the cmd_start event, which
> happens very early (maybe before config gathering?).
>
> Maybe it's better to log the parent_name as its own event, since it
> shouldn't change over the lifetime of the process?
>
> procfs is very non-portable, though - I think this won't even work on
> MacOS. So I'm curious if anybody has better suggestions for how to do
> this.
>
>   - Emily


Look at `trace2_collect_process_info()` in `trace2.h` and
`compat/win32/trace2_win32_process_info.c`.

That function is designed to let the process call out to
platform-specific code to do things like getting the name
of the invoking process.

It is called with an enum to indicate when/why it is being
called.

On Windows, I have platform code to get the process ancestry,
the peak VM usage, and whether the process is being debugged.
Two of those were easy....  And all are very platform-specific.

They all generate events of the form:

	trace2_data_*("process", "windows/<something>", ...)

Some of my `t021[012]/` helper scripts exclude "process" category
messages from the output to make the t*.sh tests portable.


To implement a /proc lookup as you have suggested, I would
fixup the Makefile or config.mak.uname to include something
like a "HAVE_..." feature and then use that at the
bottom of trace2.h to declare a trace2_collect_process_info()
function and then have your code in compat/procinfo.c hide
behind my interface.

Your code should emits events of the form:

	trace2_data_*("process", "linux/<something>", ...)

I notice there are several `PROCFS_*` symbols currently defined
in `config.mak.uname` so maybe this should be:

	trace2_data_*("process", "procfs/<something>", ...)

(I'm not sure how similar code for Linux and the various BSD
versions would be.)


Jeff

```