[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120205125325.GA31578@elastic.org>
Date: Sun, 5 Feb 2012 07:53:25 -0500
From: "Frank Ch. Eigler" <fche@...stic.org>
To: Neil Horman <nhorman@...driver.com>
Cc: Hagen Paul Pfeifer <hagen@...u.net>,
Satoru Moriya <satoru.moriya@....com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"tgraf@...radead.org" <tgraf@...radead.org>,
"stephen.hemminger@...tta.com" <stephen.hemminger@...tta.com>,
"eric.dumazet@...il.com" <eric.dumazet@...il.com>,
Seiji Aguchi <seiji.aguchi@....com>, fche@...rceware.org
Subject: Re: [PATCH v2 0/2] Tracepoint for tcp retransmission
Hi -
On Sat, Feb 04, 2012 at 03:09:37PM -0500, Neil Horman wrote:
> [...]
> Systemtap is fine for development. Lots of application/product
> vendors really don't like it. On top of the difficult to use
> aspect
(Just curious, what difficulty-to-use aspect have you more recently
come across?)
> it requires that debugging stabs info be kept with the kernel, which
> is a real pain, especially if you're running on a stable kernel.
> [...]
You probably mean when running on an unstable kernel, no? Installing
debuginfo for a stable kernel is a one-time event. It also enables
"perf probe" and crash(8) and other tools. Plus, with systemtap,
there are two separate network-remoting mechanisms (--use-server
compilation and --remote execution) that make local debuginfo
unnecessary.
Anyway, a reasonable way to go may be to prototype in stap whatever
hard-coded kernel module y'all envision finally doing this work.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists