[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
> 
> 
> 
>