Re: Event logging vs enhancing printk

[Martin J. Bligh]

>> Can you make sure that printks are not intermixed ?
> 
> show why this is a serious problem.

I already have - see earlier in this thread. Interspersed output
on SMP machines gives unreadable garbage.
 
>> I was glad to find this error log feature that meets our requirements.
>> It provides us services which reduce our development cost and provides
>> us functionality at "usual industrial level" (see e.g. POSIX).
> 
> frankly, evlog is a solution in search of a problem.  I see no reason
> printk can't do TSC timestamping, more robust and/or efficient buffering,
> auto-classification in klogd, realtime filtering/notification in
> userspace, even delaying of formatting, and logging of binary data.

Of course you could. You could just take the existing mechanism
that's been written for event logging and call it printk, for one.

But the point is to *avoid* dramatic changes to the existing subsystem
to avoid the massive pain of migration (80,000 existing calls), and
an unknown number of sysadmins with scripts to parse stuff out that
you'd drive completely mad (as we did with PTX). In the first post I 
did to this thread is a the reasoning layed out for why not to change
printk.

M.