Messages in this thread | | | Date | Thu, 13 Aug 2020 09:31:58 +0200 | From | Petr Mladek <> | Subject | Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling |
| |
On Thu 2020-08-13 02:30:02, John Ogness wrote: > On 2020-08-12, Petr Mladek <pmladek@suse.com> wrote: > > So, I have one crazy idea to add one more state bit so that we > > could have: > > > > + committed: set when the data are written into the data ring. > > + final: set when the data block could not longer get reopened > > + reuse: set when the desctiptor/data block could get reused > > > > "final" bit will define when the descriptor could not longer > > get reopened (cleared committed bit) and the data block could > > not get extended. > > I implemented this solution for myself and am currently running more > tests. Some things that I changed from your suggestion: > > 1. I created a separate prb_reserve_cont() function. The reason for this > is because the caller needs to understand what is happening. The caller > is getting an existing record with existing data and must append new > data. The @text_len field of the info reports how long the existing data > is.
I see.
> So the LOG_CONT handling code in printk.c looks something like this:
Yeah, it makes sense.
> 2. I haven't yet figured out how to preserve calling context when a > newline appears. For example: > > pr_info("text"); > pr_cont(" 1"); > pr_cont(" 2\n"); > pr_cont("3"); > pr_cont(" 4\n"); > > For "3" the calling context (info, timestamp) is lost because with "2" > the record is finalized. Perhaps the above is invalid usage of LOG_CONT?
I am going to answer Sergey's reply.
> 3. There are some memory barriers introduced, but it looks like it > shouldn't add too much complexity.
Uff. I have hooped for this.
> I will continue to refine my working version and post a patch so that we > have something to work with. This looks to be the most promising way > forward. Thanks.
Uff, I am happy that it seems working. Several other approaches looked much more complicated or they caused regressions.
Best Regards, Petr
| |