Bcc func load attachtype for bcc > 0.24.0 #311
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This is what BCC is going to be [using as base version in the future](iovisor/bcc#3808), so eventually, the current LLVM 9 will break.
|
This patch will be needed once BCC cuts a new release and gobpf wants to support it. Currently, there is no good way to use the right function signature at compile time. All that BCC provide is What is the stand of gobpf in term of bcc library support? Do we want to have gobpf backward compatible? If this is the case, having BCC expose major/minor/patch would probably help as we could add a wrapper for go to call one variant or the other depending on version. |
chantra
added a commit
to chantra/bcc
that referenced
this pull request
Jul 5, 2022
Summary: Currently, libbcc only exposes its version via a string constant. This makes it complicated for libraries built on top of libbcc to be compatible across multiple versions when there is API changes for instances, as happens in iovisor/gobpf#311 Exposing MAJOR/MINOR/PATCH versions would allow libraries which are not shipped as part of iovisor/bcc to handle those API changes. This diffs exposes those values, provides a macro to perform version comparison (a la `LINUX_VERSION()`). One thing it does not address currently is exposing whether this is an "exact tag" version, e.g a release, or in between releases. Test plan: When building: ``` -- Latest recognized Git tag is v0.24.0 -- Git HEAD is 3bab069745fe201fb032574edf87da4c3a8020c7 -- Revision major 0, minor 24, patch 0 -- Revision is 0.24.0-3bab0697 -- Found LLVM: /usr/lib/llvm-11/include 11.1.0 (Use LLVM_ROOT envronment variable for another version of LLVM) ... ... ``` and the produced `bcc_version.h`: ``` $ cat build/src/cc/bcc_version.h ```
chantra
added a commit
to chantra/bcc
that referenced
this pull request
Jul 10, 2022
Summary: Currently, libbcc only exposes its version via a string constant. This makes it complicated for libraries built on top of libbcc to be compatible across multiple versions when there is API changes for instances, as happens in iovisor/gobpf#311 Exposing MAJOR/MINOR/PATCH versions would allow libraries which are not shipped as part of iovisor/bcc to handle those API changes. This diffs exposes those values, provides a macro to perform version comparison (a la `LINUX_VERSION()`). One thing it does not address currently is exposing whether this is an "exact tag" version, e.g a release, or in between releases. Test plan: When building: ``` -- Latest recognized Git tag is v0.24.0 -- Git HEAD is 3bab069745fe201fb032574edf87da4c3a8020c7 -- Revision major 0, minor 24, patch 0 -- Revision is 0.24.0-3bab0697 -- Found LLVM: /usr/lib/llvm-11/include 11.1.0 (Use LLVM_ROOT envronment variable for another version of LLVM) ... ... ``` and the produced `bcc_version.h`: ``` $ cat build/src/cc/bcc_version.h ```
chantra
added a commit
to chantra/bcc
that referenced
this pull request
Jul 20, 2022
Summary: Currently, libbcc only exposes its version via a string constant. This makes it complicated for libraries built on top of libbcc to be compatible across multiple versions when there is API changes for instances, as happens in iovisor/gobpf#311 Exposing MAJOR/MINOR/PATCH versions would allow libraries which are not shipped as part of iovisor/bcc to handle those API changes. This diffs exposes those values, provides a macro to perform version comparison (a la `LINUX_VERSION()`). One thing it does not address currently is exposing whether this is an "exact tag" version, e.g a release, or in between releases. Test plan: When building: ``` -- Latest recognized Git tag is v0.24.0 -- Git HEAD is f26cdb33068187d04d9dc058834985df841e28fa -- Revision is 0.24.0-f26cdb33 (major 0, minor 24, patch 0) -- Found LLVM: /usr/lib/llvm-11/include 11.1.0 (Use LLVM_ROOT envronment variable for another version of LLVM) ... ... ``` and the produced `bcc_version.h`: ``` $ cat build/src/cc/bcc_version.h ```
chantra
force-pushed
the
bcc_func_load_attachtype
branch
from
56a3b00
to
9eb7933
Compare
chantra
added a commit
to chantra/bcc
that referenced
this pull request
Jul 21, 2022
Summary: Currently, libbcc only exposes its version via a string constant. This makes it complicated for libraries built on top of libbcc to be compatible across multiple versions when there is API changes for instances, as happens in iovisor/gobpf#311 Exposing MAJOR/MINOR/PATCH versions would allow libraries which are not shipped as part of iovisor/bcc to handle those API changes. This diffs exposes those values, provides a macro to perform version comparison (a la `LINUX_VERSION()`). One thing it does not address currently is exposing whether this is an "exact tag" version, e.g a release, or in between releases. Test plan: When building: ``` -- Latest recognized Git tag is v0.24.0 -- Git HEAD is f26cdb33068187d04d9dc058834985df841e28fa -- Revision is 0.24.0-f26cdb33 (major 0, minor 24, patch 0) -- Found LLVM: /usr/lib/llvm-11/include 11.1.0 (Use LLVM_ROOT envronment variable for another version of LLVM) ... ... ``` and the produced `bcc_version.h`: ``` $ cat build/src/cc/bcc_version.h ```
yonghong-song
pushed a commit
to iovisor/bcc
that referenced
this pull request
Jul 21, 2022
Summary: Currently, libbcc only exposes its version via a string constant. This makes it complicated for libraries built on top of libbcc to be compatible across multiple versions when there is API changes for instances, as happens in iovisor/gobpf#311 Exposing MAJOR/MINOR/PATCH versions would allow libraries which are not shipped as part of iovisor/bcc to handle those API changes. This diffs exposes those values, provides a macro to perform version comparison (a la `LINUX_VERSION()`). One thing it does not address currently is exposing whether this is an "exact tag" version, e.g a release, or in between releases. Test plan: When building: ``` -- Latest recognized Git tag is v0.24.0 -- Git HEAD is f26cdb33068187d04d9dc058834985df841e28fa -- Revision is 0.24.0-f26cdb33 (major 0, minor 24, patch 0) -- Found LLVM: /usr/lib/llvm-11/include 11.1.0 (Use LLVM_ROOT envronment variable for another version of LLVM) ... ... ``` and the produced `bcc_version.h`: ``` $ cat build/src/cc/bcc_version.h ```
|
iovisor/bcc#4091 made it upstream, so this should be good as it is. |
|
@schu what do you think of this PR? Anything you would like me to address? |
|
Would love to see this get merged, Thank you @chantra |
v0.25.0 introduce BCC versioning macros: iovisor/bcc@83a379e which can be used to handle API changes.
iovisor/bcc@ffff0ed a new parameter was added to control the attach type. Subsequently, in iovisor/bcc@815d1b8 , `-1` was used to signal the default behaviour. This change adds this new parameter to the call to `C.bcc_func_load` when LIBBCC_VERSION_CODE is greater or equal than 0.25.0, the next version to include the aforementioned change. Test plan: Against v0.25.0 is being tested as part of this project CI. also ran against the current v0.20.0 and ran CI: https://github.com/chantra/gobpf/runs/7436803048
chantra
force-pushed
the
bcc_func_load_attachtype
branch
from
9eb7933
to
0e5464f
Compare
|
bcc v0.25.0 was released. I have updated this PR to reflect it. @schu this should be good to go. |
6 tasks
|
Will this solve #314 ? |
yes, it should. |
sterchelen
pushed a commit
to sterchelen/bcc
that referenced
this pull request
Sep 9, 2022
Summary: Currently, libbcc only exposes its version via a string constant. This makes it complicated for libraries built on top of libbcc to be compatible across multiple versions when there is API changes for instances, as happens in iovisor/gobpf#311 Exposing MAJOR/MINOR/PATCH versions would allow libraries which are not shipped as part of iovisor/bcc to handle those API changes. This diffs exposes those values, provides a macro to perform version comparison (a la `LINUX_VERSION()`). One thing it does not address currently is exposing whether this is an "exact tag" version, e.g a release, or in between releases. Test plan: When building: ``` -- Latest recognized Git tag is v0.24.0 -- Git HEAD is f26cdb33068187d04d9dc058834985df841e28fa -- Revision is 0.24.0-f26cdb33 (major 0, minor 24, patch 0) -- Found LLVM: /usr/lib/llvm-11/include 11.1.0 (Use LLVM_ROOT envronment variable for another version of LLVM) ... ... ``` and the produced `bcc_version.h`: ``` $ cat build/src/cc/bcc_version.h ```
|
@schu could you review this? |
|
hm, @schu does not appear to be a member of https://github.com/orgs/iovisor/people anymore; and there have not been any other committer recently. (Sorry if he has access to the repository in any other way, github does not seem to provide a way of checking if he still has commit access) please forgive the mass notification -- @iovisor (iirc this notifies everyone in the group) -- is there anyone willing to shepherd gobpf? What would the way forward be here if not? |
|
Thank you @4ast! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
[bcc] Support for new
bcc_func_loadsignature.In iovisor/bcc@ffff0ed
a new parameter was added to control the attach type. Subsequently, in iovisor/bcc@815d1b8,
-1was used to signal the default behaviour.This change adds this new parameter to the call to
C.bcc_func_loadwhen LIBBCC_VERSION is greater than 0.24.0, the last cut version which
did not introduce this change.