From: Karim Yaghmour <karym@opersys.com>
To: "Collins, Tom" <Tom.Collins@Surgient.com>
Cc: "'richardj_moore@uk.ibm.com'" <richardj_moore@uk.ibm.com>,
Andreas Dilger <adilger@turbolinux.com>,
linux-kernel@vger.kernel.org
Subject: Re: Dynamically altering code segments
Date: Tue, 27 Feb 2001 20:22:57 -0500 [thread overview]
Message-ID: <3A9C544A.AB7B9071@opersys.com> (raw)
In-Reply-To: <A490B2C9C629944E85CE1F394138AF957FC3E3@bignorse.SURGIENT.COM>
"Collins, Tom" wrote:
[snip]
> I have one more question: My trace code is currently
> implemented as a kernel loadable module. Would I need
> to change that so that it is built as part of the kernel,
> or can I keep it as a loadable module? If I can keep it
> as a module, I would ensure that the module would be the
> only place that would enable/disable the trace, (don't
> want the kernel jumping to a nonexistant address :O ..)
[snip]
No need to do that, except if you modify the binary dynamically.
If that's the case, then you'll probably have to make it part
of the kernel. But ... if you modify your code to use the
pre-existing hooks that come with LTT, you may not need to
modify anything more than what is provided with by the LTT
patch. That is, you may want to know that LTT provides a
hooking mechanism similar, but less flexible, than the one
GKHI provides. The advantage, though, is that there are pre-defined
hooks inserted with the LTT patch which can be used right
away without further instrumentation.
As this type of hooking comes more and more in need, I'm
currently discussing with Richard the possibility of using
the LTT pre-defined hooks with GKHI in order to provide an
extensible hooking mechanism for the kernel that comes equipped
with an already quite useful set of hooks, which, of course,
can be dynamically enabled/disabled.
Using this type of hooking, you only need to worry about
registering/unregistering your callbacks since the kernel
doesn't jump in your code, but in the hooks management code
first.
Best regards,
Karim
===================================================
Karim Yaghmour
karym@opersys.com
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
next prev parent reply other threads:[~2001-02-28 1:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-27 19:04 Dynamically altering code segments Collins, Tom
2001-02-28 1:22 ` Karim Yaghmour [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-03-01 2:58 Jeremy Jackson
2001-02-27 18:15 richardj_moore
2001-02-27 16:43 Collins, Tom
2001-02-27 17:05 ` Andreas Dilger
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=3A9C544A.AB7B9071@opersys.com \
--to=karym@opersys.com \
--cc=Tom.Collins@Surgient.com \
--cc=adilger@turbolinux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=richardj_moore@uk.ibm.com \
/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;
as well as URLs for NNTP newsgroup(s).