-
-
Notifications
You must be signed in to change notification settings - Fork 468
linux: support for monitoring syscall #1486
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
Open
sanpeqf
wants to merge
1
commit into
htop-dev:main
Choose a base branch
from
sanpeqf:linux-syscall
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
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 hidden or 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 hidden or 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 hidden or 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 hidden or 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 hidden or 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.
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 think you are doing something wrongly here. Normally a process won't be waiting for a syscall, so the presence of a syscall number would be more of an exception rather than rule.
I won't say you can't use an enum here. But the better way is to merge this status with the syscall number, so that you don't need two member variables for recording the same thing.
Here is what I mean:
By the way, Linux syscall table for x86-64 is in
syscall_64.tbl
. The file is located in different directories in Linux source code throughout Linux versions.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 should also know that the x32 system call starts from 0x40000000, and the system call allows negative numbers to exist. Using one variable is always unsafe, but using two can completely eliminate this kind of thing and is beneficial for sorting
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.
Nah. 0x40000000 is positive. The negative should always be unused or otherwise they won't reserve -1 for the documented reason.
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.
Firstly, 0x40000000 is certainly not a negative number, but it is a special case. With one special case, there may be more. Also, if you do this, it will cause all N/A to be ranked at the top, which is not user-friendly. 😄
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.
@JohnSanpe With a mapping table implemented, you are not likely order the syscall by its number, but by the mapped name instead.
Linux assigns syscall number in a rather arbitrary way, so, with the table implemented, ordering by name would make more sense.
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.
@Explorer09 @JohnSanpe
First, i think use negative number to show a syscall state. it's unsafe. Although Linux may not currently use negative numbers as syscall ID.
Second, The state of syscall and the syscall ID themselves are actually two different things, and merging them would reduce readability.
Third, i think we can use a struct to wrapper syscall id and syscall state, like