Bug 834265
Summary: | net command should print prefix 0x before the actual addresses | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Stanislav Kozina <skozina> |
Component: | crash | Assignee: | Dave Anderson <anderson> |
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.2 | CC: | mhomolov, plyons |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-08-16 15:28:04 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Stanislav Kozina
2012-06-21 11:34:01 UTC
Sorry, that's not going to change for this command (or for all of the other commands that display structure addresses). A foundational tenet of the crash utility is the avoidance of the 0x whenever possible, both for user input and command output. And why use "px" for this example? crash> net NET_DEVICE NAME IP ADDRESS(ES) ffffffff80321e80 lo 127.0.0.1 ffff81003c058000 eth0 10.16.185.59 ffff810038ea7800 sit0 crash> net_device ffff81003c058000 struct net_device { name = "eth0\000\000\000\000\000\000\000\000\000\000\000", name_hlist = { next = 0x0, pprev = 0xffffffff804d6ed0 }, mem_end = 0, mem_start = 0, base_addr = 0, irq = 193, ... (In reply to comment #1) > Sorry, that's not going to change for this command (or for all of the other > commands that display structure addresses). A foundational tenet of the > crash utility is the avoidance of the 0x whenever possible, both for user > input and command output. And would the user distinquish hex and dec output with such tenet? What's the motivation for it? For example, by default crash outputs: crash> net_device.flags ffff880312458020 flags = 4099 Is this hex, or dec? By default crash prints some values in dec, some in hex. How can I distinquish each other without the prefix? What's the motivation for such tenet? My main concern is that 'px' command considers values which does not begin with '0x' as symbols - therefore I have to add 0x every single time I need to do some computation, which is not pleasant. > And why use "px" for this example? Because I need to get pointer to some item in the structure. Because `struct' command can't be used with -o option together with the address (bz834260), I have to compute the address myself. (In reply to comment #3) > (In reply to comment #1) > > Sorry, that's not going to change for this command (or for all of the other > > commands that display structure addresses). A foundational tenet of the > > crash utility is the avoidance of the 0x whenever possible, both for user > > input and command output. > > And would the user distinquish hex and dec output with such tenet? What's > the motivation for it? For example, by default crash outputs: > > crash> net_device.flags ffff880312458020 > flags = 4099 > > Is this hex, or dec? By default crash prints some values in dec, some in > hex. How can I distinquish each other without the prefix? > What's the motivation for such tenet? > Well, in the case above, that output is from the embedded gdb module, not from crash per se, and gdb's output depends upon the current state of its output radix -- which defaults to decimal. That's annoying taking your example of a bit-map "flags" member, but gdb sees it as just an "int". So from crash, the gdb output (and along with it, several instances of crash-only output) is controlled by the "set radix 10" or "set radix 16" commands (or the built-in "hex" and "dec" aliases). I've also recently gone through commands that display gdb structure output (struct, vm, list, net, mach, dis, and task) and added new -x and -d options that override the current radix setting. So for example: Default: crash> net_device.flags ffffffff80321e80 flags = 9 crash> Change it and redisplay: crash> hex output radix: 16 (hex) crash> net_device.flags ffffffff80321e80 flags = 0x9 crash> Change it back, but override the default: crash> dec output radix: 10 (decimal) crash> net_device.flags ffffffff80321e80 flags = 9 crash> net_device.flags ffffffff80321e80 -x flags = 0x9 crash> All of the newer -x/-d options are not yet seen in the RHEL versions of crash, but during the errata cycles I typically rebase the RHEL versions. But there's always a lag, and the GSS folks typically update their crash version from upstream on their dumpfile-hosting systems. This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. > > crash> net_device.flags ffff880312458020 > > flags = 4099 > > Well, in the case above, that output is from the embedded gdb module, not > from crash per se, and gdb's output depends upon the current state of its > output radix -- which defaults to decimal. That's annoying taking your > example of a bit-map "flags" member, but gdb sees it as just an "int". Yes, I understand the principle, I just wanted to open a discussion if this is really behavior we want. I really picked the 'flags' example because it's a bit controversial, sorry about that:-) > So from crash, the gdb output (and along with it, several instances of > crash-only output) is controlled by the "set radix 10" or "set radix 16" > commands (or the built-in "hex" and "dec" aliases). Yes, it's a good to have an option to set default output radix to 16, and I personally find it as neccessary that I have it in my crashrc file. > I've also recently gone through commands that display gdb structure > output (struct, vm, list, net, mach, dis, and task) and added new > -x and -d options that override the current radix setting. Thanks for that - might be useful. Although I personally prefer to change default output radix. > crash> net_device.flags ffffffff80321e80 -x Option can be put after the argument? In which cases? Is this a rule for all options? > All of the newer -x/-d options are not yet seen in the RHEL versions > of crash, but during the errata cycles I typically rebase the RHEL > versions. But there's always a lag, and the GSS folks typically > update their crash version from upstream on their dumpfile-hosting > systems. I see, I will really make sure to always use only current version of crash. Thanks a lot for reminding it. And GSS folks keep an eye to update the version we use on our core analysis systems, so it's current there all the time. Thanks. > Yes, it's a good to have an option to set default output radix to 16, > and I personally find it as neccessary that I have it in my crashrc file. Right, and I understand that can be a pain if you find yourself running on a machine where your $HOME/.crashrc doesn't exist. How about if I add a new "crash --hex ..." command line option? (and like most command line options, it would overrule any conflicting .crashrc entry.) > Option can be put after the argument? In which cases? Is this a rule for > all options? Sure, in pretty much all cases -- and why not? In fact, it makes it much easier if you want to rerun a prior command with a different radix -- just recall the command and append the option to the command line. This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4. |