Add Kazu, the makedumpfile maintainer in cc. On 10/31/18 at 10:26am, lijiang wrote: > 在 2018年10月30日 17:23, Baoquan He 写道: > > > > Hi Boris, DaveY and Lianbo, > > > > On 10/30/18 at 10:15am, Borislav Petkov wrote: > >> On Tue, Oct 30, 2018 at 01:09:00PM +0800, Dave Young wrote: > >>> It is not the content, I think it is a good catch from Boris, it would > >>> be good to document the exported things in somewhere eg. > >>> Documentation/kdump/vmcoreinfo.txt > > > > For the vmcoreinfo variables document, I personally think it might be > > not necessary. The reason is that all the old varialbles are exported > > with the name of themselves. We know what they are or what they > > represent since they are all kernel symbols or macro. Only this me_mask, > > it's a local variable and store the value of sme_me_mask for now, may > > store more info later like Petr mentioned, and also will store the memory > > encryption information of TME (which is intel's transparent memory encryption). > > We can add code comment around to tell these. > > > Thank you, everyone. > > I personally agree with Baoquan's opinion. What do you think about? Boris and other reviewer? > > If the vmcoreinfo document is necessary, would you like to help me to provide an outline? > I can try my best to write the document. It is true like what Baoquan said, these information are mainly used by makedumpfile tool for creating a filtered vmcore. But these vmcoreinfo hide in a lot of different code paths: kernel/crash_core.c, printk code, arch code etc. It is a mist only a few kdump people know them, documenting them will help people to understand and review. It will also be clearer instead of digging into code? The document can briefly explain what is vmcoreinfo, why we need it, and some background info. Then list the exported values with some classifying by core kernel, arch related, string or number etc. For most of them like Baoquan said no need more explanation, but add explanations for something if needed like this sme mask. But I think this can be done separately instead of blocking this patch. Maybe Kazu knows more about it, so I would like to ask Kazu about his opinion and if he want to do it. > > Anyway, we should make a choice. > > Regards, > Lianbo > > > Personal opinion. > > > > Thanks > > Baoquan > > Thanks Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
