Message-ID: <53C87E5B.2060505@linaro.org>
Date:	Thu, 17 Jul 2014 20:54:35 -0500
From:	Alex Elder <elder@...aro.org>
To:	Kay Sievers <kay@...y.org>
CC:	akpm@...ux-foundation.org, pmladek@...e.cz, bp@...e.de,
	john.stultz@...aro.org, jack@...e.cz,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/5] printk: more log flag simplification

On 07/17/2014 08:37 PM, Kay Sievers wrote:
> On Thu, Jul 17, 2014 at 7:59 PM, Alex Elder <elder@...aro.org> wrote:
>> This series rearranges the log code in such a way that the LOG_CONT
>> and LOG_PREFIX log record flags can be eliminated entirely.  The
>> result should be considerably easier to understand than before.  It
>> builds on another recently-posted series of patches:
>>     https://lkml.org/lkml/2014/7/17/363
>>
>> The first patch exploits the fact that LOG_CONT and LOG_NEWLINE
>> are inverses, and uses LOG_NEWLINE (or its negation) anywhere
>> LOG_CONT is used.  As a result, LOG_CONT is no longer needed, so
>> it's eliminated.
>>
>> The next three patches together eliminate LOG_PREFIX.  The effect
>> of LOG_PREFIX is to complete the previous log entry before recording
>> a new one.  Patch 2 arranges to do this directly, marking the previous
>> log record with LOG_NEWLINE whenever a new record is presented with
>> LOG_PREFIX set.  Patch 3 stops saving LOG_PREFIX in any log records,
>> and patch 4 finally gets rid of LOG_PREFIX.
>>
>> The last patch is just some cleanup of the code now that it's gone
>> through this transformation.
> 
> Continuation lines are racy and unreliable by definition, they create
> a problem that cannot be solved properly, so we need to try to make
> the best out of it. The idea of the record buffer flags was to record
> what actually happened when things race against each other. A line
> without a newline is recorded as a line without a newline.

Understood.

> Your simplifying patches changes the code to store how things will
> *look* like when exported, not what actually *happened*; like it
> pretends the earlier line had a newline, while that might not have
> been the case.

What do you mean by "exported?"  Does the result in syslog
or /proc/kmsg (or the console for that matter) actually
differ?  I'll have to look again, but I think they do not.

I believe with the changes I made, all log records are saved in
exactly the same order, and buffered records are merged in exactly
the same way as before.  It's just that !LOG_NEWLINE is now treated
as the same as LOG_CONT, and the effect of LOG_PREFIX is done by
"completing" the previous record.

I do see your point though, that the fact that a newline
was added by a successor entry loses the piece of information
that the previous one didn't have one originally.  Is that
significant information?  I don't believe it's visible outside
the in-core log records.

> Maybe your simplified logic is "good enough" for the common use cases,
> I haven't thought it through, but it sounds a bit strange to pretend
> things in the flags of a record which actually did not happen for this
> record that way, just to save a bit in a flag field.

It is not about saving bits, it's about making the
code more understandable.  As it was, only after
looking very hard at this to see things could be
refactored that I saw that the one case (where PREFIX
did not override a previous CONT flag) had a bug.

My sincere intention was to preserve exactly the same
behavior, but do so with fewer flags.  The net result
is the same, but you're right, I realize now there was
some information loss--I just didn't recognize that
information as important.

I really appreciate your looking this stuff over Kay.

					-Alex


> Thanks,
> Kay
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists