|| ||Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ-AT-public.gmane.org> |
|| ||Mike Waychison <mikew-hpIqsD4AKlfQT0dZR+AlfA-AT-public.gmane.org> |
|| ||Re: [PATCH v1 00/12] netoops support |
|| ||Wed, 03 Nov 2010 15:54:45 -0500|
|| ||Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w-AT-public.gmane.org>, simon.kagstrom-vI6UBbBVNY+JA8cjQkG2/g-AT-public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q-AT-public.gmane.org, adurbin-hpIqsD4AKlfQT0dZR+AlfA-AT-public.gmane.org, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b-AT-public.gmane.org,
|| ||Article, Thread
On Wed, 2010-11-03 at 13:29 -0700, Mike Waychison wrote:
> Mike Waychison wrote:
> > 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
> 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.
to post comments)