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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
