http://lkml.org/lkml/2002/4/10/24 - pretty much a dead end with one further response
- 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.
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."
Michel Dagenais: "Fine, let's call evlog "an enhanced printk" and discuss the specific technical details of the proposition. ..."