On Sun 2021-04-11 14:08:14, Joe Perches wrote: > On Sun, 2021-04-11 at 21:52 +0200, John Ogness wrote: > > I'd rather fix dev_info callers to allow pr_cont and then fix any code > > that is using this workaround. > > Assuming you mean all dev_<level>() uses, me too. > > > And if the print maintainers agree it is OK to encourage > > pr_cont(LOGLEVEL "...") usage, then people should really start using > > that if the loglevel on those pieces is important. > > I have no stong feeling about the use of pr_cont(<KERN_LEVEL> > as valuable or not. I think it's just a trivial bit that > could be somewhat useful when interleaving occurs. > > A somewhat better mechanism would be to have an explicit > cookie use like: > > cookie = printk_multipart_init(KERN_LEVEL, fmt, ...); > while (<condition>) > printk_multipart_cont(cookie, fmt, ...); > printk_multipark_end(cookie, fmt, ...); > > And separately, there should be a pr_debug_cont or equivalent.
We would need to implement this a lockless way. It is doable, for example, using some per-CPU X per-context buffers. Which would require to disable preemption in the section. But I think that using dev_cont_info() would be easier after all. That said, some printk_*_init()/end() API would be useful for storing the pieces in a temporary buffer. It would allow to store the entire lines without the risk of interleaving with other messages. Best Regards, Petr
