From: Matt Mackall <mpm@selenic.com>
To: Mike Waychison <mikew@google.com>
Cc: Greg KH <greg@kroah.com>,
simon.kagstrom@netinsight.net, davem@davemloft.net,
adurbin@google.com, akpm@linux-foundation.org, chavey@google.com,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org
Subject: Re: [PATCH v1 00/12] netoops support
Date: Wed, 03 Nov 2010 15:54:45 -0500 [thread overview]
Message-ID: <1288817685.26428.1129.camel@calx> (raw)
In-Reply-To: <4CD1C612.5080902@google.com>
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
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.
next prev parent reply other threads:[~2010-11-03 20:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-03 1:29 [PATCH v1 00/12] netoops support Mike Waychison
2010-11-03 1:29 ` [PATCH v1 01/12] Oops: Pass regs to oops_exit() Mike Waychison
2010-11-03 1:29 ` [PATCH v1 02/12] kmsg_dumper: Pass pt_regs along to dumpers Mike Waychison
2010-11-03 1:29 ` [PATCH v1 03/12] kmsg_dumper: Introduce a new 'SOFT' dump reason Mike Waychison
2010-11-03 1:29 ` [PATCH v1 04/12] sys-rq: Add option to soft dump Mike Waychison
2010-11-03 1:29 ` [PATCH v1 05/12] netoops: add core functionality Mike Waychison
2010-11-03 1:30 ` [PATCH v1 06/12] netoops: Add x86 specific bits to packet headers Mike Waychison
2010-11-03 1:30 ` [PATCH v1 07/12] netoops: Add user programmable fields to the netoops packet Mike Waychison
2010-11-03 1:30 ` [PATCH v1 08/12] netoops: Add one-shot mode Mike Waychison
2010-11-03 1:30 ` [PATCH v1 09/12] netoops: Add an interface to trigger various types of crashes Mike Waychison
2010-11-03 1:30 ` [PATCH v1 10/12] kmsg_dump: Export symbol kmsg_dump() to GPL modules Mike Waychison
2010-11-03 1:30 ` [PATCH v1 11/12] ipv4: Export arp_bind_neighbour() symbol " Mike Waychison
2010-11-03 1:30 ` [PATCH v1 12/12] netoops: Allow the driver to be built as a module Mike Waychison
2010-11-03 2:34 ` [PATCH v1 00/12] netoops support Greg KH
2010-11-03 3:37 ` Mike Waychison
2010-11-03 18:16 ` Greg KH
2010-11-03 18:50 ` Randy Dunlap
2010-11-03 19:40 ` Joe Perches
2010-11-03 20:58 ` Bruno Prémont
2010-11-03 19:03 ` Mike Waychison
2010-11-03 20:29 ` Mike Waychison
2010-11-03 20:54 ` Matt Mackall [this message]
2010-11-04 1:18 ` Mike Waychison
2010-11-04 6:35 ` Américo Wang
2010-11-04 17:38 ` Mike Waychison
2010-11-04 6:15 ` Américo Wang
2010-11-04 17:21 ` Mike Waychison
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1288817685.26428.1129.camel@calx \
--to=mpm@selenic.com \
--cc=adurbin@google.com \
--cc=akpm@linux-foundation.org \
--cc=chavey@google.com \
--cc=davem@davemloft.net \
--cc=greg@kroah.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikew@google.com \
--cc=simon.kagstrom@netinsight.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox