Simon Horman <horms at verge.net.au> writes: >> I also did all the below. Please check it. (Is anyone else reading all >> this stuff??) > > These look fine to me. Unfortunately they don't apply to the version > of Linus' tree that I have checked out and I'm away from net access > at this moment (though obviously not by the time this message reaches you). > I'll update my tree and check once I'm back online. > > Eric Biederman usually watches kexec stuff. I'm pretty sure he > is on the kexec mailing list, but I've CCed him anyway. Thanks. The question at head seems to be does it make sense to always export log_buf and log_end in the VMCOREINFO section of the core file we generate. The premise of VMCOREINFO is that it gives crash or other analysis tools enough information to pair a core dump with a vmlinux and decipher the page table layout. In general things that are tricky to infer from just the core dump, and the vmlinux. Do log_buf and log_end fall in that category? They are certainly important enough and they are symbols that are tricky to find. That said I think we should also have this information exported so that we can get at it with kgdb, jtag debuggers, and other weird debugging tools. Do we have that already? It doesn't look like it. That may be an argument for a different interface. That aside we aren't currently exporting log_buf_len, so I don't think this code works actually works. Neil can you add a comment in kernel/printk.c of the algorithm necessary for external tools to decode the ring buffer? We need the comment because people working on kernel/printk.c need to know what is happening and without having to review lots of user space code, and we need the comment to verify that we are exporting the right things. Eric
