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@xxxxxxxxxx> 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
