DLPX-92313 Fix small drgn merge conflict #61
Merged
Conversation
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
In all of our current code, we want to document a class separately from its "constructor"; see commit c801e5e ("drgndoc: format __init__() signature separately from class"). But for some trivial classes, like one that will be added in an upcoming change, it makes sense to collapse them. So, for classes with no docstring and one __init__() signature with a docstring, document the class with the __init__() signature and docstring. Signed-off-by: Omar Sandoval <[email protected]>
An upcoming helper will need these. We also need them from vmtest when _drgn may not be built yet, though, so they can't go in drgn.internal. Create a new package, _drgn_util, and move them there. Signed-off-by: Omar Sandoval <[email protected]>
An upcoming helper will need some ELF constant definitions. Signed-off-by: Omar Sandoval <[email protected]>
This will be used by an upcoming helper. Signed-off-by: Omar Sandoval <[email protected]>
…memory These are highly-requested features that I didn't implement for awhile because I thought they would be too difficult or hacky. The approach that I finally came up with is slightly deranged but solid: we manually generate a kernel module ELF file and machine code to do a function call. An alternative approach that I tried was generating C source code for a kernel module and building it, but that relies on having kernel-devel and a compatible toolchain installed, and it's slow. (Kudos to Matthew Wilcox for suggesting the kernel module approach last year: https://lwn.net/Articles/953256/.) For now, this is under a new drgn.helpers.experimental package, in the drgn.helpers.experimental.kmodify module, with no stability guarantees, but we still have tests for it. Signed-off-by: Omar Sandoval <[email protected]>
Signed-off-by: Omar Sandoval <[email protected]>
Signed-off-by: Omar Sandoval <[email protected]>
There are some diagnostic use cases where all one has is a dentry and no vfsmount. This is technically ambiguous, because a superblock may be mounted in several places due to bind mounts, filesystem namespaces, etc. The dentry's full path would depend on the specific mount point. But when we're doing debugging, we frequently just want any representative filesystem path for the dentry. It turns out that the kernel always puts new mountpoints at the end of the superblock's list of mounts, so the first one is likely to be the most relevant anyway. Thus, arbitrarily choosing this first mountpoint is a good way to get a representative path. Update d_path() to accept a single dentry as well. Signed-off-by: Stephen Brennan <[email protected]>
The only changes are that Black 24 updated the style for stubs and if-else expressions. Signed-off-by: Omar Sandoval <[email protected]>
mmaybee
approved these changes
Sep 27, 2024
jwk404
approved these changes
Oct 1, 2024
pcd1193182
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 only one conflict in this merge, when upstream modified a file we deleted (
.pre-commit-config.yaml). I kept it deleted.http://selfservice.jenkins.delphix.com/job/appliance-build-orchestrator-pre-push/9392/