On 2020-08-12, Petr Mladek <pmladek@xxxxxxxx> 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 had not thought of extending data blocks. That is clever!
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. So the LOG_CONT handling code in printk.c looks something like this:
if (lflags & LOG_CONT) {
struct prb_reserved_entry e;
struct printk_record r;
prb_rec_init_wr(&r, text_len, 0);
if (prb_reserve_cont(&e, prb, &r, caller_id)) {
memcpy(&r.text_buf[r.info->text_len], text, text_len);
r.info->text_len += text_len;
if (lflags & LOG_NEWLINE)
r.info->flags |= LOG_NEWLINE;
if (r.info->flags & LOG_NEWLINE)
prb_commit_finalize(&e);
else
prb_commit(&e);
return text_len;
}
}
This seemed simpler than trying to extend prb_reserve() to secretly
support LOG_CONT records.
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?
3. There are some memory barriers introduced, but it looks like it
shouldn't add too much complexity.
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.
John Ogness
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
