On Wed, 2010-11-03 at 13:29 -0700, Mike Waychison wrote:

Mike Waychison wrote:

quoted

FWIW, another semantic difference between netconsole and netoops (that
I had missed in the last email) is filtering: we really do want to get
the whole log when a crash happens, debug messages and all.
Netconsole is subject to console filtering (which we _do_ want as
debug messages going out the uart slows the whole world down).

netconsole and netoops _do_ have bits in common, for instance the
handling of NETDEV events and source+target configuration.  I'd rather
those bits become common between the two than figure out how to jam
the semantics we need into netconsole.

Hi Matt,

I've been reading through the netconsole driver in response to Greg's 
comments on this thread, and it is definitely more robust in terms of 
configuration and handling of network device events than the netoops 
driver I proposed.

I've been following the discussion to see if it went anywhere
interesting..

What are your thoughts on extending netconsole with the same sort of 
semantics that are in the netoops patchset?

My first thought is that it's a bit unfortunate that some of the the
netconsole configgy bits weren't implemented in a generic way that would
be applicable to other netpoll clients. Some people have never gotten it
into their heads that netconsole isn't the only client.

I'd still like to have blit-dmesg-to-the-network-on-oops semantics, 
which seems doable by having a per-target flag for streaming of console 
messages (enabled by default) and a flag to emit a structured full dmesg 
dump (disabled by default).

I'd actually like to see you go forward with netoops. It's clear to me
that it's a different beast and complexifying netconsole with a bunch of
weird new options doesn't really sit well. If that means abstracting
some of the sysfs crap from netconsole, great. 

That said, I don't think netoops is an ideal name, given how closely
bound oops _events_ are with their textual output. Presumably it covers
events other than oopsen like panics too. 

Regarding rolling oopses: lots of machines regularly survive oopses, so 
I think you ought to consider rate-limiting them (to a configurable rate
with a very low default) rather than suppressing all but the first.

-- 
Mathematics is the supreme nostalgia of our time.