RE: [Crash-utility] new printk ringbuffer interface

RE: [Crash-utility] new printk ringbuffer interface

[HAGIO KAZUHITO(萩尾 一仁)]

ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..

> -----Original Message-----
> 
> ----- Original Message -----
> > Hello Dave,
> >
> > You may or may not be aware that we are working on replacing [0] the
> > Linux printk ringbuffer. Rather than a single buffer containing a single
> > struct type, the new ringbuffer makes use of several different structs.
> 
> Yes, I am most definitely aware...
> 
> >
> > I am writing to ask your advice about how this should be exported for
> > the crash utility. Should all struct sizes and field offsets be
> > exported? It would look something like this:
> >
> >         VMCOREINFO_SYMBOL(prb);
> >
> >         VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
> >         VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
> >         VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
> >         VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
> >         VMCOREINFO_OFFSET(printk_ringbuffer, fail);
> >
> >         VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
> >         VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
> >         VMCOREINFO_OFFSET(prb_desc_ring, descs);
> >         VMCOREINFO_OFFSET(prb_desc_ring, head_id);
> >         VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
> >
> >         VMCOREINFO_STRUCT_SIZE(prb_desc);
> >         VMCOREINFO_OFFSET(prb_desc, info);
> >         VMCOREINFO_OFFSET(prb_desc, state_var);
> >         VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
> >         VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
> >
> >         VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
> >         VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
> >         VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
> >
> >         VMCOREINFO_STRUCT_SIZE(printk_info);
> >         VMCOREINFO_OFFSET(printk_info, seq);
> >         VMCOREINFO_OFFSET(printk_info, ts_nsec);
> >         VMCOREINFO_OFFSET(printk_info, text_len);
> >         VMCOREINFO_OFFSET(printk_info, dict_len);
> >         VMCOREINFO_OFFSET(printk_info, caller_id);
> >
> >         VMCOREINFO_STRUCT_SIZE(prb_data_ring);
> >         VMCOREINFO_OFFSET(prb_data_ring, size_bits);
> >         VMCOREINFO_OFFSET(prb_data_ring, data);
> >         VMCOREINFO_OFFSET(prb_data_ring, head_id);
> >         VMCOREINFO_OFFSET(prb_data_ring, tail_id);
> >
> > Or would it be enough to just recognize the new "prb" symbol and have
> > all the structures defined in the crash utility? If the latter is
> > preferred, should some sort of version number be exported? Or is the
> > kernel version number enough?

first I don't think we can depend on the kernel version because distribution
kernels backport upstream patches.  So we will need a version number of the
ringbuffer if we choose that way.

I think that "exporting all things" can sometimes reflect changes in kernel
automatically and can reduce tool side effort more than "exporting a version
number".  But the former requires a lot of entries and it might be hard for
us to track the changes.  So having an explicit version might be better and
I'm ok with the latter.

But I hope no missing update of the version number..
Any thoughts from vmcore-dmesg side?

Thanks,
Kazu

> >
> > I appreciate your feedback.
> >
> > John Ogness
> 
> With respect to the crash utility, there are two answers.
> 
> When running crash session normally, i.e. running "crash vmlinux vmcore", the runtime
> "log" command does not use any VMCOREINFO entries that happen to be attached to a dumpfile.
> Since crash has the vmlinux debuginfo data available, it uses its own interfaces to get
> all kernel symbol and structure related information.
> 
> But there is a little-used capability where the the vmlinux file is not required,
> but rather just the vmcore, in its "crash --log vmcore" feature.  That functionality
> does require the VMCOREINFO entries to extract/dump the log, and exit.  Honestly I wish
> I had never even introduced that feature.  And I wonder if it were deprecated,
> would anybody care?
> 
> However, your question is highly relevant to the makedumpfile(8) facility
> for its "makedumpfile --dump-dmesg" option.  Since it doesn't have the
> luxury of a vmlinux file, it needs all of the VMCOREINF_xxx items.  Kazuhito
> Hagio is the makedumpfile maintainer, and since he is the primary customer
> of the VMCOREINFO entries, he would be a better person to answer your
> question.
> 
> That being said, due the sheer number VMCOREINFO entries required, I like
> your idea of providing a single version number.  But I defer to Kazu for
> his preference.
> 
> Thanks,
>   Dave
> 
> 
> 
> 

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] new printk ringbuffer interface

[Dave Anderson]

----- Original Message -----
> ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> 
> > -----Original Message-----
> > 
> > ----- Original Message -----
> > > Hello Dave,
> > >
> > > You may or may not be aware that we are working on replacing [0] the
> > > Linux printk ringbuffer. Rather than a single buffer containing a single
> > > struct type, the new ringbuffer makes use of several different structs.
> > 
> > Yes, I am most definitely aware...
> > 
> > >
> > > I am writing to ask your advice about how this should be exported for
> > > the crash utility. Should all struct sizes and field offsets be
> > > exported? It would look something like this:
> > >
> > >         VMCOREINFO_SYMBOL(prb);
> > >
> > >         VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
> > >         VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
> > >         VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
> > >         VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
> > >         VMCOREINFO_OFFSET(printk_ringbuffer, fail);
> > >
> > >         VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
> > >         VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
> > >         VMCOREINFO_OFFSET(prb_desc_ring, descs);
> > >         VMCOREINFO_OFFSET(prb_desc_ring, head_id);
> > >         VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
> > >
> > >         VMCOREINFO_STRUCT_SIZE(prb_desc);
> > >         VMCOREINFO_OFFSET(prb_desc, info);
> > >         VMCOREINFO_OFFSET(prb_desc, state_var);
> > >         VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
> > >         VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
> > >
> > >         VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
> > >         VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
> > >         VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
> > >
> > >         VMCOREINFO_STRUCT_SIZE(printk_info);
> > >         VMCOREINFO_OFFSET(printk_info, seq);
> > >         VMCOREINFO_OFFSET(printk_info, ts_nsec);
> > >         VMCOREINFO_OFFSET(printk_info, text_len);
> > >         VMCOREINFO_OFFSET(printk_info, dict_len);
> > >         VMCOREINFO_OFFSET(printk_info, caller_id);
> > >
> > >         VMCOREINFO_STRUCT_SIZE(prb_data_ring);
> > >         VMCOREINFO_OFFSET(prb_data_ring, size_bits);
> > >         VMCOREINFO_OFFSET(prb_data_ring, data);
> > >         VMCOREINFO_OFFSET(prb_data_ring, head_id);
> > >         VMCOREINFO_OFFSET(prb_data_ring, tail_id);
> > >
> > > Or would it be enough to just recognize the new "prb" symbol and have
> > > all the structures defined in the crash utility? If the latter is
> > > preferred, should some sort of version number be exported? Or is the
> > > kernel version number enough?
> 
> first I don't think we can depend on the kernel version because distribution
> kernels backport upstream patches.  So we will need a version number of the
> ringbuffer if we choose that way.

With respect to the kernel version, you are absolutely correct, as we've been
burnt by that before with backports to distribution and the upstream longterm
kernels.  But I think John was talking about exporting a printk-structure-set
version number, so I think we're on the same page.

Also, if we go the version-number route, there would still not be a requirement
for the crash utility to duplicate the kernel data structures in its sources.
As John's proof-of-concept patch showed, it can still use the traditional
manner of getting structure sizes and member offsets.  With the version number
exported, there may have to be a few small adjustments in the MEMBER_OFFSET_INIT()
calls, but it would be fairly straight-forward to maintain.

But of course makedumpfile would have to replicate the kernel data structures.

Thanks,
  Dave


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [Crash-utility] new printk ringbuffer interface

[HAGIO KAZUHITO(萩尾 一仁)]

> -----Original Message-----
> ----- Original Message -----
> > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> >
> > > -----Original Message-----
> > >
> > > ----- Original Message -----
> > > > Hello Dave,
> > > >
> > > > You may or may not be aware that we are working on replacing [0] the
> > > > Linux printk ringbuffer. Rather than a single buffer containing a single
> > > > struct type, the new ringbuffer makes use of several different structs.
> > >
> > > Yes, I am most definitely aware...
> > >
> > > >
> > > > I am writing to ask your advice about how this should be exported for
> > > > the crash utility. Should all struct sizes and field offsets be
> > > > exported? It would look something like this:
> > > >
> > > >         VMCOREINFO_SYMBOL(prb);
> > > >
> > > >         VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
> > > >         VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
> > > >         VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
> > > >         VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
> > > >         VMCOREINFO_OFFSET(printk_ringbuffer, fail);
> > > >
> > > >         VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
> > > >         VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
> > > >         VMCOREINFO_OFFSET(prb_desc_ring, descs);
> > > >         VMCOREINFO_OFFSET(prb_desc_ring, head_id);
> > > >         VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
> > > >
> > > >         VMCOREINFO_STRUCT_SIZE(prb_desc);
> > > >         VMCOREINFO_OFFSET(prb_desc, info);
> > > >         VMCOREINFO_OFFSET(prb_desc, state_var);
> > > >         VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
> > > >         VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
> > > >
> > > >         VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
> > > >         VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
> > > >         VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
> > > >
> > > >         VMCOREINFO_STRUCT_SIZE(printk_info);
> > > >         VMCOREINFO_OFFSET(printk_info, seq);
> > > >         VMCOREINFO_OFFSET(printk_info, ts_nsec);
> > > >         VMCOREINFO_OFFSET(printk_info, text_len);
> > > >         VMCOREINFO_OFFSET(printk_info, dict_len);
> > > >         VMCOREINFO_OFFSET(printk_info, caller_id);
> > > >
> > > >         VMCOREINFO_STRUCT_SIZE(prb_data_ring);
> > > >         VMCOREINFO_OFFSET(prb_data_ring, size_bits);
> > > >         VMCOREINFO_OFFSET(prb_data_ring, data);
> > > >         VMCOREINFO_OFFSET(prb_data_ring, head_id);
> > > >         VMCOREINFO_OFFSET(prb_data_ring, tail_id);
> > > >
> > > > Or would it be enough to just recognize the new "prb" symbol and have
> > > > all the structures defined in the crash utility? If the latter is
> > > > preferred, should some sort of version number be exported? Or is the
> > > > kernel version number enough?
> >
> > first I don't think we can depend on the kernel version because distribution
> > kernels backport upstream patches.  So we will need a version number of the
> > ringbuffer if we choose that way.
> 
> With respect to the kernel version, you are absolutely correct, as we've been
> burnt by that before with backports to distribution and the upstream longterm
> kernels.  But I think John was talking about exporting a printk-structure-set
> version number, so I think we're on the same page.
> 
> Also, if we go the version-number route, there would still not be a requirement
> for the crash utility to duplicate the kernel data structures in its sources.
> As John's proof-of-concept patch showed, it can still use the traditional
> manner of getting structure sizes and member offsets.  With the version number
> exported, there may have to be a few small adjustments in the MEMBER_OFFSET_INIT()
> calls, but it would be fairly straight-forward to maintain.
> 
> But of course makedumpfile would have to replicate the kernel data structures.

Ah, indeed.  I vaguely thought makedumpfile also might be able to do like crash
by setting sizes and offsets for each version..  But it will be hard to set them
manually for every architectures.  I'll think about it more.

Thanks,
Kazu

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: [Crash-utility] new printk ringbuffer interface

[HAGIO KAZUHITO(萩尾 一仁)]

> -----Original Message-----
> > -----Original Message-----
> > ----- Original Message -----
> > > ccing kexec list, vmcore-dmesg also uses vmcoreinfo related to printk..
> > >
> > > > -----Original Message-----
> > > >
> > > > ----- Original Message -----
> > > > > Hello Dave,
> > > > >
> > > > > You may or may not be aware that we are working on replacing [0] the
> > > > > Linux printk ringbuffer. Rather than a single buffer containing a single
> > > > > struct type, the new ringbuffer makes use of several different structs.
> > > >
> > > > Yes, I am most definitely aware...
> > > >
> > > > >
> > > > > I am writing to ask your advice about how this should be exported for
> > > > > the crash utility. Should all struct sizes and field offsets be
> > > > > exported? It would look something like this:
> > > > >
> > > > >         VMCOREINFO_SYMBOL(prb);
> > > > >
> > > > >         VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
> > > > >         VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
> > > > >         VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
> > > > >         VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
> > > > >         VMCOREINFO_OFFSET(printk_ringbuffer, fail);
> > > > >
> > > > >         VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
> > > > >         VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
> > > > >         VMCOREINFO_OFFSET(prb_desc_ring, descs);
> > > > >         VMCOREINFO_OFFSET(prb_desc_ring, head_id);
> > > > >         VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
> > > > >
> > > > >         VMCOREINFO_STRUCT_SIZE(prb_desc);
> > > > >         VMCOREINFO_OFFSET(prb_desc, info);
> > > > >         VMCOREINFO_OFFSET(prb_desc, state_var);
> > > > >         VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
> > > > >         VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
> > > > >
> > > > >         VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
> > > > >         VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
> > > > >         VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
> > > > >
> > > > >         VMCOREINFO_STRUCT_SIZE(printk_info);
> > > > >         VMCOREINFO_OFFSET(printk_info, seq);
> > > > >         VMCOREINFO_OFFSET(printk_info, ts_nsec);
> > > > >         VMCOREINFO_OFFSET(printk_info, text_len);
> > > > >         VMCOREINFO_OFFSET(printk_info, dict_len);
> > > > >         VMCOREINFO_OFFSET(printk_info, caller_id);
> > > > >
> > > > >         VMCOREINFO_STRUCT_SIZE(prb_data_ring);
> > > > >         VMCOREINFO_OFFSET(prb_data_ring, size_bits);
> > > > >         VMCOREINFO_OFFSET(prb_data_ring, data);
> > > > >         VMCOREINFO_OFFSET(prb_data_ring, head_id);
> > > > >         VMCOREINFO_OFFSET(prb_data_ring, tail_id);
> > > > >
> > > > > Or would it be enough to just recognize the new "prb" symbol and have
> > > > > all the structures defined in the crash utility? If the latter is
> > > > > preferred, should some sort of version number be exported? Or is the
> > > > > kernel version number enough?
> > >
> > > first I don't think we can depend on the kernel version because distribution
> > > kernels backport upstream patches.  So we will need a version number of the
> > > ringbuffer if we choose that way.
> >
> > With respect to the kernel version, you are absolutely correct, as we've been
> > burnt by that before with backports to distribution and the upstream longterm
> > kernels.  But I think John was talking about exporting a printk-structure-set
> > version number, so I think we're on the same page.
> >
> > Also, if we go the version-number route, there would still not be a requirement
> > for the crash utility to duplicate the kernel data structures in its sources.
> > As John's proof-of-concept patch showed, it can still use the traditional
> > manner of getting structure sizes and member offsets.  With the version number
> > exported, there may have to be a few small adjustments in the MEMBER_OFFSET_INIT()
> > calls, but it would be fairly straight-forward to maintain.
> >
> > But of course makedumpfile would have to replicate the kernel data structures.
> 
> Ah, indeed.  I vaguely thought makedumpfile also might be able to do like crash
> by setting sizes and offsets for each version..  But it will be hard to set them
> manually for every architectures.  I'll think about it more.

makedumpfile has some architecture or kernel version specific values in it and
switches them by conditions, but the reason why we can do this is that they are
mostly constants that rarely change and can be got from the kernel source easily.
With respect to structure sizes and memger offsets, I don't think of a way to do
this easily.

And then if we define all the structures in makedumpfile with the version number,
how can we implement them and switch for each version?  The new ringbuffer is
structured very much, I cannot imagine that it can be handled efficiently.

Any ideas?

If there is no efficient way, we will need all of the entries in VMCOREINFO.

Thanks,
Kazu


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] new printk ringbuffer interface

[John Ogness]

On 2020-04-23, HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab@nec.com> wrote:
>> Should all struct sizes and field offsets be exported? It
>> would look something like this:
>>
>>         VMCOREINFO_SYMBOL(prb);
>>
>>         VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
>>         VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
>>         VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
>>         VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
>>         VMCOREINFO_OFFSET(printk_ringbuffer, fail);
>>
>>         VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
>>         VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
>>         VMCOREINFO_OFFSET(prb_desc_ring, descs);
>>         VMCOREINFO_OFFSET(prb_desc_ring, head_id);
>>         VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
>>
>>         VMCOREINFO_STRUCT_SIZE(prb_desc);
>>         VMCOREINFO_OFFSET(prb_desc, info);
>>         VMCOREINFO_OFFSET(prb_desc, state_var);
>>         VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
>>         VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
>>
>>         VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
>>         VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
>>         VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
>>
>>         VMCOREINFO_STRUCT_SIZE(printk_info);
>>         VMCOREINFO_OFFSET(printk_info, seq);
>>         VMCOREINFO_OFFSET(printk_info, ts_nsec);
>>         VMCOREINFO_OFFSET(printk_info, text_len);
>>         VMCOREINFO_OFFSET(printk_info, dict_len);
>>         VMCOREINFO_OFFSET(printk_info, caller_id);
>>
>>         VMCOREINFO_STRUCT_SIZE(prb_data_ring);
>>         VMCOREINFO_OFFSET(prb_data_ring, size_bits);
>>         VMCOREINFO_OFFSET(prb_data_ring, data);
>>         VMCOREINFO_OFFSET(prb_data_ring, head_id);
>>         VMCOREINFO_OFFSET(prb_data_ring, tail_id);
>
> If there is no efficient way, we will need all of the entries in
> VMCOREINFO.

It seems like a lot to export everything, but I don't have a problem
with it. If we decide to export everything (which I expect we will need
to do), then I would change my crash(8) implementation to also rely only
on the VMCOREINFO. I see no point in having some implementations using
debug data and other implementations using VMCOREINFO data, if
VMCOREINFO has everything that is needed.

John Ogness

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: [Crash-utility] new printk ringbuffer interface

[Dave Anderson]

----- Original Message -----
> On 2020-04-23, HAGIO KAZUHITO(萩尾　一仁) <k-hagio-ab@nec.com> wrote:
> >> Should all struct sizes and field offsets be exported? It
> >> would look something like this:
> >>
> >>         VMCOREINFO_SYMBOL(prb);
> >>
> >>         VMCOREINFO_STRUCT_SIZE(printk_ringbuffer);
> >>         VMCOREINFO_OFFSET(printk_ringbuffer, desc_ring);
> >>         VMCOREINFO_OFFSET(printk_ringbuffer, text_data_ring);
> >>         VMCOREINFO_OFFSET(printk_ringbuffer, dict_data_ring);
> >>         VMCOREINFO_OFFSET(printk_ringbuffer, fail);
> >>
> >>         VMCOREINFO_STRUCT_SIZE(prb_desc_ring);
> >>         VMCOREINFO_OFFSET(prb_desc_ring, count_bits);
> >>         VMCOREINFO_OFFSET(prb_desc_ring, descs);
> >>         VMCOREINFO_OFFSET(prb_desc_ring, head_id);
> >>         VMCOREINFO_OFFSET(prb_desc_ring, tail_id);
> >>
> >>         VMCOREINFO_STRUCT_SIZE(prb_desc);
> >>         VMCOREINFO_OFFSET(prb_desc, info);
> >>         VMCOREINFO_OFFSET(prb_desc, state_var);
> >>         VMCOREINFO_OFFSET(prb_desc, text_blk_lpos);
> >>         VMCOREINFO_OFFSET(prb_desc, dict_blk_lpos);
> >>
> >>         VMCOREINFO_STRUCT_SIZE(prb_data_blk_lpos);
> >>         VMCOREINFO_OFFSET(prb_data_blk_lpos, begin);
> >>         VMCOREINFO_OFFSET(prb_data_blk_lpos, next);
> >>
> >>         VMCOREINFO_STRUCT_SIZE(printk_info);
> >>         VMCOREINFO_OFFSET(printk_info, seq);
> >>         VMCOREINFO_OFFSET(printk_info, ts_nsec);
> >>         VMCOREINFO_OFFSET(printk_info, text_len);
> >>         VMCOREINFO_OFFSET(printk_info, dict_len);
> >>         VMCOREINFO_OFFSET(printk_info, caller_id);
> >>
> >>         VMCOREINFO_STRUCT_SIZE(prb_data_ring);
> >>         VMCOREINFO_OFFSET(prb_data_ring, size_bits);
> >>         VMCOREINFO_OFFSET(prb_data_ring, data);
> >>         VMCOREINFO_OFFSET(prb_data_ring, head_id);
> >>         VMCOREINFO_OFFSET(prb_data_ring, tail_id);
> >
> > If there is no efficient way, we will need all of the entries in
> > VMCOREINFO.
> 
> It seems like a lot to export everything, but I don't have a problem
> with it. If we decide to export everything (which I expect we will need
> to do), then I would change my crash(8) implementation to also rely only
> on the VMCOREINFO. I see no point in having some implementations using
> debug data and other implementations using VMCOREINFO data, if
> VMCOREINFO has everything that is needed.

Please don't -- the crash utility supports ~15 different dumpfile
formats, the majority of which do *not* contain VMCOREINFO data.

For that reason, I try to avoid using VMCOREINFO data whenever possible,
precisely because the relevant data can be gathered from the vmlinux symbol
table and debuginfo data.

Dave


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec