[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060919194515.GB18646@redhat.com>
Date: Tue, 19 Sep 2006 15:45:15 -0400
From: "Frank Ch. Eigler" <fche@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc: linux-kernel@...r.kernel.org,
Christoph Hellwig <hch@...radead.org>,
Andrew Morton <akpm@...l.org>, Ingo Molnar <mingo@...hat.com>,
Greg Kroah-Hartman <gregkh@...e.de>,
Thomas Gleixner <tglx@...utronix.de>,
Douglas Niehaus <niehaus@...s.ku.edu>,
Tom Zanussi <zanussi@...ibm.com>,
Paul Mundt <lethal@...ux-sh.org>, Jes Sorensen <jes@....com>,
Richard J Moore <richardj_moore@...ibm.com>,
William Cohen <wcohen@...hat.com>,
"Martin J. Bligh" <mbligh@...igh.org>,
Michel Dagenais <michel.dagenais@...ymtl.ca>,
systemtap@...rces.redhat.com, ltt-dev@...fik.org
Subject: Re: [PATCH] Linux Kernel Markers 0.2 for Linux 2.6.17
Hi -
On Tue, Sep 19, 2006 at 03:36:24PM -0400, Mathieu Desnoyers wrote:
> [...]
> > If you don't allow yourself to presume on-the-fly function
> > recompilation, then these markers would need to be made run-time
> > rather than compile-time configurable. That is, not like this:
> > [...]
> By making them run-time configurable, I don't see any whay not to bloat the
> kernel. How can be embed calls to printk+function+kprobe+djprobe without
> having some kind of performance impact ?
In order to have what we appear to need, we cannot avoid having some
impact. (Even NOPs have impact.)
Suppose that mbligh's clever but speculative idea has some nasty flaw,
once someone tried to reduce it to code. Do you see that markers
along the lines you've posted would be unsatisfactory? With that in
mind, is there point adding such markers now?
- FChE
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists