linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Vamsi Krishna S ." <vamsi@in.ibm.com>
To: Werner Almesberger <wa@almesberger.net>
Cc: Richard J Moore <richardj_moore@uk.ibm.com>,
	Rob Landley <landley@trommello.org>,
	linux-kernel@vger.kernel.org,
	S Vamsikrishna <vamsi_krishna@in.ibm.com>
Subject: Re: 2.4 Ready list - Kernel Hooks
Date: Thu, 24 Oct 2002 13:08:35 +0530	[thread overview]
Message-ID: <20021024130835.A30737@in.ibm.com> (raw)
In-Reply-To: <20021023165009.I1421@almesberger.net>; from wa@almesberger.net on Wed, Oct 23, 2002 at 09:50:15PM +0000


On Wed, Oct 23, 2002 at 09:50:15PM +0000, Werner Almesberger wrote:
> Oops, missed that one, sorry ! I was looking at the interface
> functions, but making the hooks themselves GPL-only is even
> better.
>
Yes, I have done that in the latest patch.
 
> > I don't envisage having an arbitrary set of hook points scattered
> > throughout the kernel.
> 
> Let's hope you're right :-)
> 
kernelhooks is similar to notifier lists (include/linux/notifier.h),
only much faster when there are no users. This patch does not
add any hooks itself, I am sure placement of each hook will be
critically reviewed.

> But wouldn't a small extension of kprobes get you pretty much
> the same functionality/performance:
>
> <snip nice idea>
>
Yes, this is possible, but I think using hooks is much cleaner.

> The advantage over hooks would be that users of this mechanism
> wouldn't have to choose between fast but intrusive (hooks) and
> slow but flexible (probes).
> 
As I see it, hooks should be used for allowing other kernel code
to tap into certain well defined paths in the kernel, say in
trap 3 or trap 1 handlers in the kernel to allow multiple 
kernel-level breakpointing tools. Or, certain well defined paths
(potentially fast paths) for traceing purposes, where it is 
necessary to ensure that for the most time there are no users 
of these hooks and their placement alone should place minimal 
overhead.

So, hooks are designed, placed at well thought-out locations.
Probes OTOH are mostly ad-hoc. While debugging a problem, if
you find the need to probe a specific code location for more
info, put a probe there, on the fly, with out going through 
the recompile and reboot cycle.

> Now, it's non-trivial to do a "return from caller" with
> [kd]probes. I haven't looked at that part yet. Do you have the
> infrastructure for this ?
> 
No, returning from caller will be much harder with [kd]probes.

Hope this clarifies the issue.

Thanks,
Vamsi.
-- 
Vamsi Krishna S.
Linux Technology Center,
IBM Software Lab, Bangalore.
Ph: +91 80 5044959
Internet: vamsi@in.ibm.com

  reply	other threads:[~2002-10-24  7:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23 16:47 2.4 Ready list - Kernel Hooks Richard J Moore
2002-10-23 19:50 ` Werner Almesberger
2002-10-24  7:38   ` Vamsi Krishna S . [this message]
2002-10-24 17:22     ` Werner Almesberger
  -- strict thread matches above, loose matches on Subject: below --
2002-10-24 16:38 Richard J Moore
2002-10-24 17:02 ` Greg KH
2002-10-23  8:10 Richard J Moore
2002-10-23 17:09 ` Greg KH
2002-10-22 23:09 Richard J Moore
2002-10-22 23:54 ` Greg KH
2002-10-23 15:28 ` Werner Almesberger
2002-10-23 16:21   ` Karim Yaghmour
2002-10-21 12:24 Richard J Moore
2002-10-22 21:02 ` Werner Almesberger

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=20021024130835.A30737@in.ibm.com \
    --to=vamsi@in.ibm.com \
    --cc=landley@trommello.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richardj_moore@uk.ibm.com \
    --cc=vamsi_krishna@in.ibm.com \
    --cc=wa@almesberger.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;
as well as URLs for NNTP newsgroup(s).