-
Notifications
You must be signed in to change notification settings - Fork 481
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
Linux extensions patches #1039
Linux extensions patches #1039
Conversation
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.
So, happy with the get_symbol_table_name()
changes, happy with the refcnt
change, but the big changes in the middle will need more explanation and detail as to why they're being done that way, what the end goal is (since it's not clear that's the best way of doing it) and I making a change to the API will be a lot messier than otherwise, so if possible please avoid that like the plague. Unfortunately it doens't look like this code has accurate type signatures yet, but if they were there mypy would be complaining loudly that they no longer matched. Happy for you to either resubmit the first two small changes and get them merged quickly, or for you to hold them up whilst we talk over the bigger change, but unfortunatly this won't get merged as is...
Hello again, EDIT : I moved this part of the comment to the corresponding conversation. Thanks for your time and review :) ! Regards, |
The two previous commits include more comments, use of utilities functions, changing the config path and a general implementation following more closely the Volatilty2 one. |
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.
Here's some replies. I don't mind changing how things work, but if we do we need to follow our own rules about such changes. Since the API is public, someone else may be using it even if we're not, so removing it (or changing how it returns) would require a major version bump. Adding a new one just requires a minor version bump (and we should add a deprecation notice to the old function).
See here for an example of how we do deprecation.
Hello, I took notice of the different scenarios regarding deprecation. I think the best option is to keep the existing functions inputs and outputs types, and add, in a second time, functions that does what I initially (re)implemented. To do so, I made a dedicated function to get the I kept the All already existing functions still have the same inputs and outputs types, but have their core logic changed, which I hope should only result in a "patch" number bump :) |
Hi👋, I would like to know if the team had any news or plans regarding this PR. Indeed, I have some plugins, planned to be released as "community plugins", that depend on these edits. |
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.
Hiya, generally no complaints. I'd probably update the config name, but that can be changed without any effect later, so happy to merge this if you don't want to update it now. Just let me know either way and we'll get it merged...
self.context, | ||
self.config_path, | ||
self._context, | ||
"config_name_elf_symbol_table", |
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'd ditch the config_name
at the start of this. It's in the configuration, so the config_name
is kind of implicit/seems a little odd...
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.
As I'm not sure to fully understand what you want me to do with the config_name, I'd prefer if you could change it later.
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.
Just change it from "config_name_elf_symbol_table",
to "elf_symbol_table",
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.
Oh, I thought you were talking about the field type, not the string. Ok this makes sense indeed !
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.
Just spotted a few breaking changes. I thought you were just adding functions, but you took the old ones away, rather than deprecating them.
You can add the warning in like this and you can even use the new method to produce the results, but the function needs to return the same outputs when given the same inputs as the original.
I added type hinting, as requested. Regarding your other comments, I answered directly in the corresponding conversation 👍. |
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.
Cool, I'll make the config_name
change in a bit then... 5:)
module class :
Reading symbols of an arbitrary module :