Mark Hahn wrote:
>
> user-space ones, fine. you ex-mainframers have yet to demonstrate
> any sane argument for why printk is bad. for instance, it would be
> utterly trivial to add high-res timestamps. trivial to make klogd
> a little more efficient. no reason you can't plug your own
> analysis code into it, rather than the normal syslog approach.
> logging pid/gid/etc is nonsense for many, even most printk's.
I am not saying that printk is bad.
I use it myself, too, for what it is for.
During the bring up, test, debug phase it is useful.
Can you make sure with printk-s that no error log is lost, can
you tell when a log has actually reached a permanent store device ?
Can you force the people to use the same printk format ?
( I am still not good at artificial intelligence and
I am too lazy to modify my analysis code every time when somebody
modifies a printk. :-) )
Can you pass lots of data through a printk ?
Can you make sure that printks are not intermixed ?
(You need to revise all the printk-s: one event - a single printk.
Otherwise the mutex does not protect what you print.)
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).
Regards,
Zoltan Menyhart
P.S.: Please CC your answers to Zoltan.Menyhart@bull.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Apr 15 2002 - 22:00:20 EST