On Thu 2020-07-09 09:09:31, John Ogness wrote: > 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. I know that it might be premature question. But I wonder what kind of changes are expected because of the continuous lines. Do you expect some changes in the ring buffer structures so that the debugging tools would need yet another update to actually access the data? Or do you expect backward compatible changes that would allow to pass related parts of the continuous lines via syslog/dev_kmsg interface and join them later in userspace? IMHO, it would make sense to wait only when the structures need some modification. Concatenating related parts on the userspace side will need to stay optional anyway. As I say, this might be premature question. I just do not want to unnecessary delay mainlining the current state. It would get much wider testing there. And it is great when the changes might be done in "small" steps. Best Regards, Petr _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
