Tyler Yahn

> I think that the Go Automatic Instrumentation should "by default" set the global providers and use them as well. @pellared how do you set the global provider in another...

> I think that while having another "go native" opentelemetry SDK living alongside the eBPF SDK in the same process is technically feasible @blumamir the eBPF instrumentation will never live...

### Notes from SIG meeting: - We need to support trace context propagation regardless of the unified or bifurcated pipeline question - We want to support the situation where a...

@pellared the [proposed solution](https://github.com/open-telemetry/opentelemetry-go-instrumentation/pull/523 ) to [(2)] is adding support to capture from the default global implementation. It will not capture telemetry from any SDK registered with the global implementation,...

> Have we considered or attempted to construct trace & metrics providers and inject them into the process? Wouldn't this violate the Go memory management requirements? We would be using...

@grcevski is planning to address this or find an owner.

@grcevski @RonFed ^

Automation of this documentation is tracked in https://github.com/open-telemetry/opentelemetry-go-instrumentation/issues/908.

Looks like a good starting point to me 👍

On second thought, we don't handle any events. No need to document those conf opts.