[3/n] new(libscap): platform abstraction support: clean up scap_init_*_int #1042
Conversation
gnosek
changed the title
gnosek
changed the title
|
/milestone 0.12.0 |
gnosek
force-pushed
the
platform3
branch
4 times, most recently
from
25ecef1
to
c2ed438
Compare
gnosek
force-pushed
the
platform3
branch
4 times, most recently
from
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>
gnosek
changed the title
There was a problem hiding this comment.
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. |
|
[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?: