From: "David S. Miller" <redacted>
Date : 06/16/2003 05:13 PM
egrep "promiscuous mode" net/core/dev.c | grep printk
I noticed when I performed the grep, the printk shows:
printk(KERN_INFO "device %s %s promiscuous mode\n"
For the sake of consistency and automatic error log analysis, it might be
nice to standardize on a message closer to:
printk(KERN_INFO "%s: %s promiscuous mode\n"
It's somewhat common, but not universal to start the error message with the
device name followed by a colon.
Janice
From: Janice Girouard [off-list ref]
Date: Mon, 16 Jun 2003 17:29:15 -0500
For the sake of consistency and automatic error log analysis, it might be
And all the scripts checking for the existing messages
in log files? Screw them, right?
This whole idea is starting to leave a very bad taste in
my mouth...
David S. Miller wrote:
From: Janice Girouard [off-list ref]
Date: Mon, 16 Jun 2003 17:29:15 -0500
For the sake of consistency and automatic error log analysis, it might be
And all the scripts checking for the existing messages
in log files? Screw them, right?
Are you saying we never get to change any current
log messages ever again on accnt of the scripts that are
monitoring for those precise words? Hope not :)
I'd agree a lot of thought (and agreement :))has to go
into this before changing minor nits and stuff, and not
causing too much disruption..Evolution, as opposed to
revolution ;). I would hope that most wouldnt need changing..
thanks,
Nivedita
From: Nivedita Singhvi [off-list ref]
Date: Mon, 16 Jun 2003 15:45:20 -0700
[ I removed this kenistonj@us.ibm.com from the CC:, it bounces... ]
I'd agree a lot of thought (and agreement :))has to go
into this before changing minor nits and stuff, and not
causing too much disruption..Evolution, as opposed to
revolution ;). I would hope that most wouldnt need changing..
There would be absolutely ZERO disruption if you guys would use you
brains and implement what you're actually trying to achieve, a system
event logging mechanism.
We have a message queueing mechanism using sockets, called netlink,
and you can make whatever actions in the kernel you think should be
monitored go and stuff messages into this system event netlink socket.
Then, you don't have to standardize a bunch of absolutely silly
strings (I mean, the concept is so incredibly stupid), you get events
that are in a precisely defined format going over this netlink socket.
Then whoever in userspace reads out the messages can interpret them
however the fuck it wants to. It is then trivial to parse the
messages and filter them. Furthermore, you could even transmit such
messages over a network connection to a remote logging server as-is.
And hey, look, for network links going up and down we have the hooks
already. Funny that...
David S. Miller wrote:
There would be absolutely ZERO disruption if you guys would use you
brains and implement what you're actually trying to achieve, a system
event logging mechanism.
We have a message queueing mechanism using sockets, called netlink,
and you can make whatever actions in the kernel you think should be
monitored go and stuff messages into this system event netlink socket.
I should clarify here that I was speaking strictly for my lonesome sorry
self :), and have no knowledge of what the state of the various
RAS projects currently are, and the approaches they are trying..
For all I know, they may be currently trying precisely that..
Janice's patch is the first I've seen in this area (Luckily,
most of the time they keep me in a cave :) :)), and I do
appreciate *something* being done in this area, it seemed a
good start and really, I dont care how its implemented, I'll
leave that to the folks who have spent longer than the
8 mins I currently have on it..
Then, you don't have to standardize a bunch of absolutely silly
strings (I mean, the concept is so incredibly stupid), you get events
that are in a precisely defined format going over this netlink socket.
Well, right now, thats all we have, right? Silly strings? But
thats not really my position, which is more like:
Whatever! Whatever! Somebody! Make it so! :) :).
Then whoever in userspace reads out the messages can interpret them
however the fuck it wants to. It is then trivial to parse the
messages and filter them. Furthermore, you could even transmit such
messages over a network connection to a remote logging server as-is.
And hey, look, for network links going up and down we have the hooks
already. Funny that...
OK, that is a good idea.. :)
thanks,
Nivedita