Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Donating ebpf based instrumentation #4

Closed
wants to merge 16 commits into from

Conversation

edeNFed
Copy link
Contributor

@edeNFed edeNFed commented Aug 3, 2022

This PR contains a copy of all the files in the https://github.com/keyval-dev/opentelemetry-go-instrumentation repository

@tigrannajaryan
Copy link
Member

Please make sure to follow the attribution guidelines. All source code files should carry the corresponding copyright notice. If you copied any files from other open-source projects that they need to carry the attribution notice.

Also, is ebpf-based/vmlinux.h generated or it is a copy from somewhere else? If generated please include generation instruction, if copied it needs an attribution.

@edeNFed
Copy link
Contributor Author

edeNFed commented Aug 4, 2022

Added. I followed the same licenses that cilium (another eBPF based CNCF project) use for their Go code / eBPF programs.

ebpf-based/Makefile Outdated Show resolved Hide resolved
@tigrannajaryan
Copy link
Member

Added. I followed the same licenses that cilium (another eBPF based CNCF project) use for their Go code / eBPF programs.

@edeNFed Thank you. To help with the review, can you please tell which files are derived/copied from elsewhere and which files are authored by yourself?

For files that are derived/copied we will need to know their original licenses, since not every license is allowed.

For files that you are the author are you the sole author or you are contributing this on behalf of other authors / on behalf of a company?

@edeNFed edeNFed requested a review from a team October 23, 2022 14:50
@edeNFed edeNFed marked this pull request as draft October 23, 2022 14:52
@edeNFed edeNFed marked this pull request as ready for review October 31, 2022 09:30
@edeNFed
Copy link
Contributor Author

edeNFed commented Oct 31, 2022

@tigrannajaryan The files in include/libbpf directory are copied from the linux kernel: https://github.com/torvalds/linux/tree/master/tools/lib/bpf
All the other files are written by myself and are donated on behalf of Keyval.
Please let me know if there are still attribution issues.

@open-telemetry/go-instrumentation-approvers would love to get a review for this PR.

@pellared
Copy link
Member

@tigrannajaryan The files in include/libbpf directory are copied from the linux kernel: https://github.com/torvalds/linux/tree/master/tools/lib/bpf All the other files are written by myself and are donated on behalf of Keyval. Please let me know if there are still attribution issues.

@open-telemetry/go-instrumentation-approvers would love to get a review for this PR.

The libbpf is dual-licensed. IANAL but I have no idea how we should say that we are "choosing" the BSD-2-Clause as LGPL-2.1 may be problematic, because of:

Each time you redistribute the Library (or any work based on the Library), the recipient automatically receives a license from the original licensor to copy, distribute, link with or modify the Library subject to these terms and conditions.

Any ideas?

@edeNFed
Copy link
Contributor Author

edeNFed commented Oct 31, 2022

Those files are needed for easy linkage during compilation. I am not sure if this makes the decision easier but I guess we can download them during the compilation script instead of having a copy in this repo.

Anyway, I think there should be a way to use those files as other eBPF based projects in the CNCF (cilium for example) are also dependent on them.

@pellared
Copy link
Member

Those files are needed for easy linkage during compilation. I am not sure if this makes the decision easier but I guess we can download them during the compilation script instead of having a copy in this repo.

It is not about "storing" the code but the fact that the library is linked.

Reference: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html

Anyway, I think there should be a way to use those files as other eBPF based projects in the CNCF (cilium for example) are also dependent on them.

That does not guarantee that these repositories are OK from legal perspective 😉

For instance, AFAIK, MIT requires adding a copywrite notice / EULA.

@pellared
Copy link
Member

pellared commented Oct 31, 2022

My "perfectionist ego" forced me to create open-telemetry/community#1280 to track the issue from the OTel organization perspective. I hope nobody is going to hate me for it 😉

I think we should consider deferring the licensing "issue" I brought (we can create an issue for it).

At this point of time I think it is fine to use libbpf using the "precedence rule".

@tigrannajaryan
Copy link
Member

tigrannajaryan commented Nov 3, 2022

BSD is explicitly allowed by Otel provided that the notice is retained which it is is, so we are good: https://github.com/open-telemetry/community/blob/main/CONTRIBUTING.md#copyright-notices

Copy link
Contributor

@damemi damemi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edeNFed, this is a really cool project. Separating each library the way you have done gives it a neat modular-manager design that makes this easily extensible in the future.

I left some comments for future ideas but I am +1 to merging this if there's nothing blocking us (mainly because I want to get my hands dirty and start contributing myself!)

include/utils.h Outdated Show resolved Hide resolved
cli/main.go Outdated
"github.com/open-telemetry/opentelemetry-go-instrumentation/pkg/process"
)

func main() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

follow-up: help/usage text would be useful

return nil
}

func ParseTargetArgs() *TargetArgs {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

any consideration for command line flags? Or at least a centralized struct for storing the various required arguments (process exe, collector endpoint, service name)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 99 to 104
insts := []Instrumentor{
grpc.New(),
grpcServer.New(),
httpServer.New(),
gorillaMux.New(),
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like how modular this is, it looks like it will make adding support for new libraries fairly easy in the future. wonder if this could eventually be made customizable rather than hard-coded for people to support their own libraries

}

func (i *Injector) getFieldOffset(libName string, libVersion string, structName string, fieldName string) (uint64, bool) {
for _, l := range i.data.Data {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the docs:

Luckily for us, there is a way to analyze the target binary and extract the required offsets, by using DWARF. The DWARF debug information is generated by the compiler and is stored inside the binary.
Notice that one of our design goals is to support stripped Go binaries - meaning binaries that do not contain debug information. In order to support stripped binaries and to create a stable instrumentation, we created a library called offsets-tracker.

does this mean that in non-stripped binaries, we could retrieve, store, and access the offset data without needing to do this loop?

I also wonder if there are ways to optimize this data structure, maybe something we could look into if it saves a significant amount of time

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree. this loop can probably be skipped for non-stripped binaries.
Also +1 for creating a better data structure.

Copy link
Member

@pellared pellared left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaving just one comment to make sure that this donation is safe from the legal perspective.

include/libbpf/bpf_endian.h Outdated Show resolved Hide resolved
@pellared
Copy link
Member

I am approving as I think that this PR is too big to process it in a regular way. I suggest merging it as it is. People can always look at this PR and add comments. We may address comments as separate PRs

Copy link
Member

@dineshg13 dineshg13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed at SIG meeting , we should be good to merge this .

jmacd and others added 8 commits November 16, 2022 09:04
Co-authored-by: Robert Pająk <pellared@hotmail.com>
Define the CODEOWNERS file as owned by the project maintainers and all
else owned by the approvers. This define the required reviews for
modification of the owned files.
Check the GitHub actions for updates weekly.
@edeNFed edeNFed closed this Nov 16, 2022
MikeGoldsmith pushed a commit that referenced this pull request Jun 14, 2023
Merge upstream main, add changelog and make small fixes
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants