lkml.org 
[lkml]   [2020]   [Aug]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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

    \
     
     \ /
      Last update: 2020-08-13 09:32    [W:5.306 / U:3.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site