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