On 2020-07-08, Petr Mladek <pmladek@xxxxxxxx> wrote: > OK, I think that we are ready to try this in linux-next. > I am going to push it there via printk/linux.git. > > [...] > > Of course, there are still many potential problems. The following comes > to my mind: > > [...] > > + Debugging tools accessing the buffer directly would need to > understand the new structure. Fortunately John provided > patches for the most prominent ones. The next series in the printk-rework (move LOG_CONT handling from writers to readers) makes some further changes that, while not incompatible, could affect the output of existing tools. It may be a good idea to let the new ringbuffer sit in linux-next until the next series has been discussed/reviewed/merged. After the next series, everything will be in place (with regard to userspace tools) to finish the rework. As reminder, here are all the steps planned for the full rework: 1. replace ringbuffer 2. implement NMI-safe LOG_CONT (i.e. move handling to readers) 3. remove logbuf_lock 4. remove safe buffers 5. implement per-console printing kthreads 6. implement emergency mode and write_atomic() support 7. implement write_atomic() for 8250 UART Some of the steps may be combined into a single series if the changes are not too dramatic. John Ogness _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
