-
Notifications
You must be signed in to change notification settings - Fork 164
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
[3/n] new(libscap): platform abstraction support: clean up scap_init_*_int #1042
Conversation
/milestone 0.12.0 |
25ecef1
to
c2ed438
Compare
aecbf47
to
0d82297
Compare
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
We are about to use the checks for all engines (if they don't support API versions, the check will be a no-op) so we cannot provide the functions in a Linux-only library. Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
Signed-off-by: Grzegorz Nosek <grzegorz.nosek@sysdig.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree it's a tiny patch on top we should merge ASAP for consistency.
/approve
Just had a general question I am noticing just now and if we want to address it, it needs to be a separate PR anyways:
For the plugin use case we have platform = scap_generic_alloc_platform();
where .init_platform
is NULL in that vtable. However for the Falco metrics use case we rely on lookups part of scap_linux_init_platform
(host boot ts or gethostname, num_cpus ...) and then also scap_linux_retrieve_agent_info
for fetching the start_time for CPU usage calculation in sinsp resource utilization module.
And then @jasondellaluce would know better re the aspect of plugins now exposing syscalls event source and we have more extensions planned, so I was curious as to why HAS_ENGINE_SOURCE_PLUGIN
doesn't get a linux platform as well while understanding that for some cases we don't need the proc scan etc. Ideas how to consolidate all these use cases @gnosek?
And then just some naming nits struct scap_platform_vtable scap_generic_platform_vtable
but static const struct scap_platform_vtable scap_linux_platform
could also add a _vtable
suffix for clarity. But again this is not about the changes in this PR.
LGTM label has been added. Git tree hash: 077706412b35f03dfb1ca084745788aa52f60d3c
|
<3
So I suppose we can move machine_info and agent_info into the generic platform, but then it will have to compile everywhere (obviously doable), and this will have to go in in 0.12 too, to avoid breaking your use case. I'll see what I can do :)
Short term: add a flag like for the test_input engine to let you choose between generic and linux platforms (I'd expect many source plugins won't care about processes or network interfaces so we shouldn't make them pay the cost). Long term: just open whatever platform you wish, it's going to be independent from the engine anyway. Currently (as of 4/n) there shouldn't be any places where a specific engine is tied to a specific platform, except for scap_init and friends that tie engines and platforms together, so it's "only" a matter of exposing a usable API. You probably won't want to use the savefile platform for the gvisor engine :D but apart from the top-level API, nothing prevents you from using e.g. an all new and improved platform with an existing engine or vice versa.
Oops :) my excuse is that scap_linux_platform isn't visible outside the file it's defined in but you're right, I should clean that up. Now let's bikeshed whether we want to add _vtable or remove it :) |
Thanks @gnosek I'll be available to review the PR around the minor extension for the plugins case. re the other question I directed also to Jason I am not yet too knowledgeable about the plugins and they are still evolving, so just wanted to highlight that we should all double check where we are heading wrt to plugins. re the naming, it's really not too important rn. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: FedeDP, gnosek, incertum 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 libscap
Does this PR require a change in the driver versions?
What this PR does / why we need it:
After the giant buildup of #1040 and #1041, this puts the cherry on top and unifies all the scap_init_*_int into one.
Special notes for your reviewer:
This PR is huge since it contains #1040 and #1041 inside. It will get manageable after they're done.
Does this PR introduce a user-facing change?: