[Crash-utility] [PATCH] display MCNT and PRIVATE when using kmem -p

[Dave Anderson]

----- Original Message -----
> At 2012-2-28 23:37, Dave Anderson wrote:
> >
> >
> > ----- Original Message -----
> >> At 2012-1-10 21:54, Dave Anderson wrote:
> >>>
> >>>
> >>> ----- Original Message -----
> >>>> Hello Dave,
> >>>>
> >>>> Glad to hear the capability is desirable. I will start to
> >>>> implement this
> >>>> soon.
> >>>>
> >>>
> >>>>>> What if I change struct sub-command to this:
> >>>>>>
> >>>>>> 1. it can refer to anonymous members (e.g., page._mapcount)
> >>>>>> 2. it can refer to submembers(e.g., page._count.counter)
> >>>
> >>> One other suggestion -- I believe it should not be necessary to
> >>> support the "page._count.counter" format, because you can get
> >>> the data by using the container name.  Taking the "_count.counter"
> >>> example:
> >>>
> >>>     crash>   p ((struct page *)0xffffea0000000200)._count.counter
> >>>     $10 = 0
> >>>     crash>   p ((struct page *)0xffffea0000000200)._count
> >>>     $11 = {
> >>>       counter = 0
> >>>     }
> >>>     crash>
> >>>
> >>> So using "page._count" should suffice.
> >>>
> >>> Thanks,
> >>>     Dave
> >>>
> >>> --
> >>> Crash-utility mailing list
> >>> Crash-utility at redhat.com
> >>> https://www.redhat.com/mailman/listinfo/crash-utility
> >>>
> >>>
> >> Hello Dave,
> >>
> >> Sorry for reacting late. I have started to realize these item we talked
> >> before. But, considering your mail about "page._count.counter" format, I
> >> need to explain my opinion to you. Trying to support the
> >> "page._count.counter" format is used to help implementing the formatted
> >> output like:
> >>
> >> crash>  struct page.flags,_count.counter -..<  PAGE_list.txt
> >>        1024    0
> >>        1024    1
> >>        1024    1
> >>        1024    1
> >>
> >> Compared with "p ((struct page
> >> *)0xffffea0000000200)._count.counter",
> >> which can only display only one data each time, the former style can be
> >> more helpful when parsing the output.
> >>
> >> The reason why I want the "page._count.counter" format is I want to
> >> offer an efficient way to collect a lot of data. Then I'd like you to
> >> give some comments. Thanks.
> >
> > I'm not interested in completely changing the output format of the "struct"
> > command to display the raw data for multiple fields on a single line as
> > you've shown in your example above.  It's completely redefining the output
> > format of the command.  If you want to implement something like that, it
> > would have to be governed by a new output option, expressed something like:
> >
> >   crash>  struct -<raw-output-option>  page.flags,_count.counter
> >
> > And if you were to do something like that, then I still maintain that the
> > "page._count.counter" format is unnecessary.  You're going to be dumping
> > the whole structure behind the scenes, and then parsing for whatever fields
> > you're looking for.
> 
> Do you mean you don't accept changing the output format or simplely the
> "page._count.counter" format?
> 
> As we talk before, I want to get "_count.counter" of several pages.  So
> the "page._count.counter" format comes up, which is not acceptable.  If
> you can accept changing the output format by using a new output option,
> just like:
> 
>       flags = 0
>       _count = {
>         counter = 0
>       }
>       ...
> 
> change to:
> 
>    "0 {0} ..." or "0 { counter = 0 } ..." or 0 "{ .counter = 0 } ..."
> 
> Actually the original code is easy to read, but hard to parse. So please
> think about the above change.

Look, the original "struct.member" command format -- where both the member
name and its contents are pulled from the full structure output and displayed
individually is *not* going to change.  

As I said before, if you would like to propose a new "struct -x" option
that displays the data in a single line or something to that effect,
post a patch and I'll consider it.  But keep in mind, what you feel
is useful may be considered hard to use by others.  

Also, given that this whole discussion has *completely* revolved around
picking out data from the kernel's page structures, I'm beginning
to think that you might want to consider writing a "page" extension module
that deals only with the kernel's page structures -- parsing them, pulling
out data, finding pages with particular data contents, etc., something that
goes well beyond "kmem -p" or "struct", and which can be easily enhanced. 
And if the module gathers interest, we can then consider polishing it up for
inclusion as a regular command.

Dave