[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <y0m8xkfer8v.fsf@ton.toronto.redhat.com>
Date: 19 Sep 2006 12:49:20 -0400
From: fche@...hat.com (Frank Ch. Eigler)
To: Martin Bligh <mbligh@...gle.com>
Cc: Ingo Molnar <mingo@...e.hu>,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Paul Mundt <lethal@...ux-sh.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Jes Sorensen <jes@....com>, Andrew Morton <akpm@...l.org>,
Tom Zanussi <zanussi@...ibm.com>,
Richard J Moore <richardj_moore@...ibm.com>,
Michel Dagenais <michel.dagenais@...ymtl.ca>,
Christoph Hellwig <hch@...radead.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
William Cohen <wcohen@...hat.com>, ltt-dev@...fik.org,
systemtap@...rces.redhat.com, Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH] Linux Kernel Markers
Martin Bligh <mbligh@...gle.com> writes:
> [...] "compiled anew from original sources after deployment" seems
> the most practical to do to me. From second hand info on using
> systemtap, you seem to need the same compiler and source tree to
> work from anyway [...]
Not quite. Systemtap does not look at sources, only object code and
its embedded debugging information. (How many distributions keep
around compilable source trees?)
> [...] It seems like all we'd need to do is "list all references to
> function, freeze kernel, update all references, continue", [...]
One additional problem are external references made *by* the function.
Those too would all have to be relocated to the live data.
Live code patching is theoretically useful for all kinds of things,
but I've never heard it described as relatively simple before! :-)
- FChE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists