[Crash-utility] multiple structs with the same name

[Ben Myers]

Hi Dave, 

On Fri, Jun 15, 2012 at 09:06:22AM -0400, Dave Anderson wrote:
> ----- Original Message -----
> > Hi Dave,
> > 
> > On Thu, 14 Jun 2012 15:45:55 -0400 (EDT)
> > Dave Anderson <anderson at redhat.com> wrote:
> > 
> > [snip]
> > 
> > > 
> > > So I suppose we *could* have a new crash "block" environment variable,
> > > settable with the "set" command, and then while it's in play you would
> > > see stuff based upon that particular scope.  Hmmm...
> > > 
> > > I just wonder if it's worth it given the parcity of actual examples of
> > > multiple structs with the same name.  That's why I'm wondering if
> > > anybody else on the list has run into this kind of problem?
> > 
> > If I remember correctly, I already had such a problem some time ago and
> > IMHO it would be very useful to have the possibility in crash to define
> > the current context.
> > 
> > Michael
> 
> Yeah, OK -- in fact, I've got to believe that there must be examples
> that exist within the base kernel itself, and not just with modules.

Cliff Wickman (my neighbor down the hall @ SGI) sent me a list of additional
examples:

some duplicate structure/enumerations in 3.0.13
 d_partition
 disklabel
 dma_chan
 getdents_callback
 hpet_dev
 ioapic
 irq_info
 mm_slot
 move_type
 netlbl_domhsh_walk_arg
 node
 pci_root_info

These haven't been a problem for me yet... but I'm glad to hear that XFS isn't
the only offender!

> Anyway, for crash-6.0.8 I'll queue up a "set context" (or "set scope"?) 
> environment variable that takes a kernel/module text address -- with
> a default of 0 to keep the behavior the same as it is now.

Great!  Thanks for looking into this.  For now, we're planning on renaming our
XFS struct log to struct xlog... It probably should have been anyway.

Thanks,
	Ben