-
Notifications
You must be signed in to change notification settings - Fork 321
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
Add /proc/modules
support
#476
base: master
Are you sure you want to change the base?
Conversation
Taints: []string{}, | ||
} | ||
|
||
if size, err := strconv.ParseUint(parts[1], 10, 64); err == nil { |
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.
Is it expected that the parsing might fail? If not, we should just abort here and return the error then silentely ignoring it.
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.
Is it expected that the parsing might fail?
Yes, I think it's possible. Checking the error could also prevent from spec changes. (too low possibility, but still would be better than not checking instead.)
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 but I don't like that we silentely ignore the error here. Why not return an error if err != nil?
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.
Why not return an error if err != nil?
That's because I noticed this err == nil
pattern in some places. For example, arp:
Line 98 in 0c4b3aa
if mac, err := net.ParseMAC(columns[3]); err == nil { |
Line 186 in 0c4b3aa
if err == nil { |
I agree with you, returning an error would better. I can return an error if you want. Wdyt?
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.
@SuperQ wdyt? But yeah I think returning an error would be better
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.
Yes, returning the error would be better.
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.
@Dentrax Can you change this so we can merge it?
Signed-off-by: Furkan <[email protected]>
Taints: []string{}, | ||
} | ||
|
||
if size, err := strconv.ParseUint(parts[1], 10, 64); err == nil { |
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.
Yes, returning the error would be better.
@Dentrax Just a nit, but can you add |
Signed-off-by: Furkan [email protected]
I have some use-cases for this implementation:
/proc/interrupts
file using procfs package (with go:linkname)All tests passes.
Fixes #478