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