-
Notifications
You must be signed in to change notification settings - Fork 169
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
new: plugin capabilities, dropping get_type
API
#274
Conversation
…anage extraction and event source as capabilities. This allows to easily implement new feature on top of current API by adding more capabilities. Signed-off-by: Federico Di Pierro <nierro92@gmail.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.
Love this! I think this is a big step forward for the design of the plugin system. Thanks Fede!
|
||
// | ||
// Interface for a sinsp/scap extractor plugin | ||
// Small C interface that is passed down to libscap |
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.
I'm not strong about this, but for my personal taste I would avoid adding an additional struct just for this and pass down to scap a plugin_api*
instead. For the goal of reducing the plugin function visibility, I think an approach like the one of #213 will be the way to go once it will get merged. For the goal of storing state variables, I feel like this would not suffice anyways if we'll decide to support multiple source plugins. We can leave things as they are here for now, but we'll probably need to refactor this a little bit in the future!
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.
Yeah, i agree with you!
I think that at the moment it makes no big difference and the needed refactor will be pretty small once #213 (or a similar design) is merged.
I am not sure how to currently store needed state variables too :)
LGTM label has been added. Git tree hash: 589e3545c05a07c9131aaef5997315a0c22149d1
|
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Federico Di Pierro <nierro92@gmail.com> Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com>
Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.com> Signed-off-by: Federico Di Pierro <nierro92@gmail.com> Co-authored-by: Jason Dellaluce <jasondellaluce@gmail.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.
/approve
LGTM label has been added. Git tree hash: 8443504650b5254c1838ef89e6202545a19385a2
|
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.
Thank you very much for this amazing job @FedeDP! IMHO the capabilities approach is much clearer than the previous one with types :)
Signed-off-by: Federico Di Pierro <nierro92@gmail.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.
/approve
LGTM label has been added. Git tree hash: 1b7294f822dc125fa779f9f45ebf7650048cc3a9
|
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: Andreagit97, FedeDP, 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 feature
Any specific area of the project related to this PR?
/area libscap
/area libsinsp
What this PR does / why we need it:
See #259:
Basically, we want to drop the
get_type
plugin API because it has no great use cases, and instead does not allow us to add new plugin types without breaking API.Plugin capabilities notion enters the chat:
get_type
C function is not needed anymore; plugin caps will be automatically detected from exported symbolsWhich issue(s) this PR fixes:
Fixes #259
Special notes for your reviewer:
Does this PR introduce a user-facing change?: