[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