-
Notifications
You must be signed in to change notification settings - Fork 165
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
chore(driver): allow kmod and bpf drivers different components #1709
chore(driver): allow kmod and bpf drivers different components #1709
Conversation
… install. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
…ike we do for kmod. Signed-off-by: Federico Di Pierro <nierro92@gmail.com>
/milestone 0.15.0 |
Please double check driver/API_VERSION file. See versioning. /hold |
Need to fix EDIT: ouch of course because it needs falcosecurity/driverkit#302 |
Driverkit 0.17.0 was released, and driverkit related tests now pass fine. |
/unhold |
/cc @jasondellaluce |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: FedeDP, jasondellaluce, leogr The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind cleanup
Any specific area of the project related to this PR?
/area build
/area driver-kmod
/area driver-bpf
Does this PR require a change in the driver versions?
What this PR does / why we need it:
This PR has a main scope: allow to install kmod and bpf under different components.
Also, now the ebpf probe gets built under
CMAKE_CURRENT_BINARY_DIR
instead ofCMAKE_CURRENT_SOURCE_DIR
, in a similar way to kmod.Moreover, to properly build the bpf probe, all the
driver/*.h
header files are copied underCMAKE_CURRENT_BINARY_DIR
for bpf and get eventually installed when issuingmake install
.It has the main advantage that in the future we might want to split up
falco-kmod
andfalco-bpf
packages, BUT still retain the possibility to build the bpf probe under/usr/src/driverversion/bpf/
folder.An example of the aforementioned issue is the current behavior if we configure libs using:
and then
make install
it. Under/usr/src/$version/
we will just have abpf
folder, and if we move under it, we cannot build the bpf probe because its sources include headers from the parent (that was not installed).Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: