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.