-
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: Add support for threads in both lsof and sockstat plugins. #1263
Merged
ikelos
merged 9 commits into
volatilityfoundation:develop
from
gcmoreira:linux_lsof_refactoring_fixes_and_improvements
Oct 7, 2024
Merged
Changes from 3 commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
867c8e3
Linux: Add support for threads in both lsof and sockstat plugins.
gcmoreira aecd31f
Add missing pointer verification
gcmoreira 32eaeeb
Fix typing typo
gcmoreira d7d84b4
Merge branch 'develop' into linux_lsof_refactoring_fixes_and_improvem…
gcmoreira cffad87
Linux: sockstat. Fix #1271 which unnecessarily extends the interface …
gcmoreira bf02723
Linux: lsof plugin: Fix module import to stick to the style guide
gcmoreira bf19b9f
Linux: lsof plugin: Fix dataclasses import to stick to the style guide
gcmoreira 2859d7a
Linux: lsof plugin: Fix list_fds() return typing
gcmoreira ee75964
Linux: lsof plugin: Fix typo in docstring
gcmoreira File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back 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.
I know these are built-in, but please can we stick to the style guide we use, which says all imports should be modules rather than methods, classes or objects please (
typing
gets a free pass)? This prevents people importinglsof.astuple
and thinking that's where it's defined. See https://google.github.io/styleguide/pyguide.html#22-importThis also applies to datetime which was previously correctly imported.
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.
hm sorry but that's the Google style guide.. is it mentioned anywhere that we stick to Google's? why?
We should stick to the Python's styles guide which is the PEP8 ... PEP 8 – Style Guide for Python Code , for which that's perfectly fine.. actually there is an example that shows that's correct:
Also for classes:
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.
It's actually from the Volatility style guide from 2014 which is mostly in alignment with PEP8 with some extra requests. I thought that was a bit terse and difficult to read, so I pointed you at Google's style guide which is longer with more discussion, but here's the original text:
** It pollutes the namespace and causes confusion. Previous versions of volatility allowed people to import functions from files they weren't defined in.
** Again, namespace pollution and inappropriate imports.
The entire rest of the code base is formatted that way and it's better to have a style guide than not. I honestly didn't expect this request to be a big sticking point? Can you explain why allowing namespace pollution is a better stylistic option than our current one, or is your disagreement just that the documentation was provided by Google and that code comes out slightly longer?
The style guide needs updating (it still includes formatting that's handled by black now, rather than yapf at the time) and it could do with reformatting since some justifications are at the same level as the bullet points they're justifying.
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.
No worries. I will take care of this.
I'm not saying it's better, but it's unclear to me why this is a concern now. I've never heard it mentioned in any of my previous contributions or by others.
We'll also need to fix this, if we want to make an exception with Typing, in about 50 other imports. Otherwise, there are 244 imports to address.
Also, Volatility2 is a separate project, so we can't expect people to refer to it for guidance on writing code for Volatility3. Volatility3 should have its own dedicated style guide page, or clear instructions of which style guide we use.
I wonder if there's a way to include that as a rule in Black. Any idea? By the way, Black follows Python's PEP8 style guide.
I also learned we have a .style.yapf file, which configures the Yapf Python formatted from Google.
This .style.yapf file doesn't specify any
based_on_style
, which means it's defaulting to PEP8 as the style guide. However, it seems we can switch it to Google's style guide if preferred. See formatting-stylebased_on_style = google
Maybe, if we are going to use Google's style guide we should use Yapf instead of Black.
Otherwise, it might be a good idea to remove that file, since it creates confusion about which formatter the project actually uses.
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.
You can go back through previous pull requests. Where I've spotted it I should have always asked for it to be corrected (and provided the rationale). Most people stick with it, I'm disappointed I missed it for 244 imports! 5:( It's possible I had quibbled a lot about the PRs and was feeling sorry for them having to fix so many things, but I feel it's saved us for lots of cross-imports between plugins and the core so I think it's a worthwhile guideline to have.
Yep, fair point, the style guide never got pulled across to vol 3 I don't think and I didn't want to sit down and rewrite it again (I didn't even tidy up the one we had), but we should.
I don't think black has that as a flag (I don't think black has many flags, to be fair). If you find one, it would be great to apply it to our automatic black check, so that it's applied to all PRs evenly when people submit them!
Yeah, that's the style mechanism we used very early on, it was deprecated years ago but I guess I didn't remove the file. I've taken care of that now. Yapf was very bad, it would reweight something, and then because of the reweighting running it again would change it back, meaning it never reached a stable equilibrium. It's the reason we moved to black.
We don't use the Google style guide exclusively, but there are a couple of points in it that make sense, such as only importing modules (in fact, that's the main one I can think of), which we've carried over. As mentioned the main style guide is in general PEP 8.