>> A similar item, 23 - logging from Dynix/ptx EES, see http://lkml.org/lkml/2002/4/9/142 originally unearthed by error27 - was reprieved by Wells. This is a Negative Know-how item and, on procedural grounds, she didn't toss those items. <<

OK: let's take a look.

This specific post is actually in the middle of a very long thread, entitled "Event logging vs enhancing printk" by Martin J. Bligh and which was started Mon, 08 Apr 2002 16:18:28 -0700.

For a little background, here's the copyright block from ~/linux-2.6.15/kernel/printk.c frome the 2.6-25 kernel source code that I've downloaded to use as a reference:

/*
 *  linux/kernel/printk.c
 *
 *  Copyright (C) 1991, 1992  Linus Torvalds
 *
 * Modified to make sys_syslog() more flexible: added commands to
 * return the last 4k of kernel messages, regardless of whether
 * they've been read or not.  Added option to suppress kernel printk's
 * to the console.  Added hook for sending the console messages
 * elsewhere, in preparation for a serial line console (someday).
 * Ted Ts'o, 2/11/93.
 * Modified for sysctl support, 1/8/97, Chris Horn.
 * Fixed SMP synchronization, 08/08/99, Manfred Spraul
 *     manfreds@colorfullife.com
 * Rewrote bits to get rid of console_lock
 *      01Mar01 Andrew Morton 
 */

So it looks right off the bat that the last modification was "Rewrote bits to get rid of console_lock" on/by "01Mar01 Andrew Morton <andrewm@___.___.au>"

Remember that date: March 1, 2001.

Why? Because the LKML thread at issue here starts on April 8, 2002 -- thirteen months later.

And how does the thread start? Mr Martin J. Bligh:

"Sorry to drag up an old thread again, but Larry Kessler and I have been having some conversations about this subject over the last week, and I said I'd post the conclusions we came to. There's a reference to the more general plans for Event Logging at: http://evlog.sourceforge.net/

1. Making any significant changes to the way we call existing printk subsystem is going to be extremely unpopular - the sheer bulk of changes needed to make this kind of update, the mindshift for future developers, and the number of patches that aren't yet in the mainline kernel that we'd break makes this unfeasible.

2. Making any significant changes to the way we log existing messages into /var/log/messages et al via syslog is going to be extremely unpopular - it will break sysadmin's setups and log parsing scripts.

<snip>

Given these constraints, it seems like it may be best to leave the printk subsystem more or less "as is", ...

<snip>

Hopefully this all makes sense, I know much of this has been stated before, but it seems useful to pull together the current set of thoughts in one summary.

M."

So, thirteen months after the last acknowledged change in printk.c we have a thread started by Martin Bligh, and he's rather apologetic about even bringing it up.

Bligh responds to various specific kernel logging issues/questions in:

http://lkml.org/lkml/2002/4/8/172

http://lkml.org/lkml/2002/4/10/24 - pretty much a dead end with one further response

http://lkml.org/lkml/2002/4/9/81 - pretty much another dead end

http://lkml.org/lkml/2002/4/9/92 - and another...

And here, although a lot of theoretical discussion has taken place, it begins to sound like Bligh is maybe kinda sorta getting a little testy: http://lkml.org/lkml/2002/4/9/166

"You want to fix 80000 printks? Be my guest ... I await your patch eagerly.
If you mean changing printk with a wrapper to help clean up the existing mess in an automated fashion, that's exactly what's being proposed.

> Evlog side-by-side with printk adds significat bloat.

To what? A kernel with event logging switch on? Sure. But if you don't want it, don't turn it on. If it's a config option, I don't see why anyone would care."

And way out at the end of that thread sits this statement by a Mr Brian Beattie:

"> You want to fix 80000 printks? Be my guest ... I await your patch eagerly.
> If you mean changing printk with a wrapper to help clean up the existing
> mess in an automated fashion, that's exactly what's being proposed.

how nice of you to say so. As to automating, I don;t believe it can work. You will be adding volume to the log, making the log processing more complicated, a replay of EES."

What's ESS, you might ask? Note that someone other than Bligh brings this up first.

And here then, way out at the end of a thread, and never receiving any response, lies TSCOG's alleged bombshell:

" ... In my mind, this should make everone happy. You obviously have some issue with this - as far as I can tell, that seems to be tied to your concepts of EES (for those that don't know, EES was Dynix/PTX's "error event subsystem" or some such name). This is not EES, nor ever will be - EES's major design flaw was that it pervasively invaded everything throughout the kernel, requiring every equivalent of printk to be changed to a complex log event. It also took away the existing subsystem equivalent to what ends up in /var/log/messages, breaking logging parsing scripts. Nobody (that I know of) is proposing doing any such thing to Linux. On the other hand customers liked the new more powerful ability to search the error scripts, and automatically generate events from that, such as email, paging, etc. FWIW, I was the Sequent customer service rep for EES.

We are trying to get for Linux the benefits of EES without the associated pain. In more specific reply to what you said, we'd be adding volume to the evlog *if* you turned evlog on, making log processing more complex *if* you turned evlog on, and this is not EES. This gives people who want evlog that functionality, and people who don't want it no change. If people object to buffering the normal printk per line, we don't have to do that. That was a side observation, not a critical part of this - in fact if it's not fixed, it just provides one more reason for people to use evlog.

OK: so at the very dead end of a dead end thread we learn Mr Bligh was a customer service rep for EES.

And finally at this dead end we learn that what Bligh is describing in this LKML thread is "not EES, nor ever will be".

And out at this dead end it's someone other than Bligh who brings up EES-Dynix/ptr first.

And in fact, the last two posts in the specific thread are made to Brian Beattie, and not to Bligh at all, and they seem to be going with Beattie's thinking.

http://lkml.org/lkml/2002/4/10/36

Denis Vlasenko: "Sounds ok for me. It will be difficult to push it into mainline kernel. I tried to fix loglevels in some printks. Patches were _trivial_ but nevertheless they weren't taken."

http://lkml.org/lkml/2002/4/11/99

Michel Dagenais: "Fine, let's call evlog "an enhanced printk" and discuss the specific technical details of the proposition. ..."

So after all that, does it sound like Martin J. Bligh imparted critical Negative Know-how from his experience with Dynix/PTX and EES at Sequent onto the Linux Kernel Mail List and thus save the Linux Kernel developers from months of wasted effort chasing squirrels up the wrong printk tree?

No. Nothing of the sort.

Only after someone else brought up EES did Bligh for the first time respond that he himself had personal experience with EES at Sequent, and even then the mention of EES-Sequent-Dynix/PTX was completely peripheral to the course of the thread at large.

And at any rate, was this entire thread crucial to, or even involved peripherally with, the development of the Linux kernel?

No. Not in the least.

This entire thread was a compilation of one position's current thinking on an issue -- "Event logging vs enhancing printk" -- in April of 2002, and one where that position did not seem even to prevail within this thread, let alone affect the evolution of the printk.c file in the Linux kernel which had been last altered -- apparently for the last time until the 2.6-15 kernel -- 13 months earlier.

AFAICS, the only real question here is just how TSCOG thinks it can put forth this crap without getting called on it...

i_s_g

< EOM >