Re: Event logging vs enhancing printk

[Karim Yaghmour <karym@opersys.com>]

"Martin J. Bligh" wrote:
> > 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.

True,

I've been following this debate for some time and it seems to me that
there's been a lot of arguments for or against an "enhanced printk".
As Michel Dagenais pointed out, we can give it the name we would like,
it is the technical merits of the evlog proposal which should be looked
at carefully.

Since everyone seems to agree that printk needs to be changed and since
the evlog folks have already worked extensively on this issue, it would
seem that their work should be weighed in and, at the very least, tested
out by the folks who insist on an "enhanced printk".

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karym@opersys.com
      Embedded and Real-Time Linux Expert
===================================================