public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Ernie Petrides <petrides@redhat.com>
To: Jim Keniston <jkenisto@us.ibm.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>,
	Linda Wang <lwang@redhat.com>,
	        systemtap@sources.redhat.com
Subject: Re: [RFC][PATCH 1/2] uprobes: utrace-based user-space probes
Date: Fri, 11 May 2007 22:31:00 -0000	[thread overview]
Message-ID: <200705112217.l4BMHZ0l013676@pasta.boston.redhat.com> (raw)
In-Reply-To: Your message of "Thu, 10 May 2007 15:13:39 PDT."              <1178835219.3753.13.camel@ibm-ni9dztukfq8.beaverton.ibm.com>

On Thursday, 10-May-2007 at 15:13 PDT, Jim Keniston wrote:

> On Tue, 2007-05-08 at 20:50 -0400, Ernie Petrides wrote:
>
> > On Monday, 7-May-2007 at 11:42 PDT, Jim Keniston wrote:
> > 
> > > On Fri, 2007-05-04 at 21:07 -0400, Ernie Petrides wrote:
> > >
> > > > Secondly, I'd recommend that everything except the consumer/infrastructure
> > > > interface be moved from include/linux/uprobes.h to kernel/uprobes.c in
> > > > order to prevent a consumer module from using/modifying/depending on
> > > > anything that it shouldn't.  This is simply basic "information hiding"
> > > > to prevent future incompatibility issues.
> > >
> > > arch/*/kernel/uprobes.c typically needs access to certain internal
> > > data structures (uprobe_kimg, uprobe_task), so I think the best we
> > > could do for some of those data structures is to move them to a
> > > separate "implementation" header.  I don't see much precedent for
> > > that, but I'm open to examples.
> > 
> > Right.  I'm suggesting moving all internal-only-use declarations out of
> > the one header file and *into* the only C source file that needs them.
> 
> Again, uprobe_kimg and uprobe_task are used both in kernel/urobes.c and
> the architecture-specific uprobes.c.  So is uprobe_ssol_slot.  But I
> should be able to move some other struct decls to uprobes.c.

Oh, one more thing on this subject.  Now that I've understood the need
for some internal-use-only declarations being in a header file, I would
not recommend creating a 2nd header file.  Maybe you could bracket the
internal stuff with an "#ifdef UPROBES_INTERNAL_USE_ONLY" and then define
that identifier inside the C files (before the uprobes.h inclusion) for
the uprobes infrastructure (but not in the example).

But the key thing is to make the consumer interface functions and structures
free of any internal-use-only declarations so you can easily preserve the
uprobes kABI (to a 3rd-party uprobes consumer module).

Cheers.  -ernie

  parent reply	other threads:[~2007-05-11 22:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-05  1:05 Ernie Petrides
2007-05-07 19:42 ` Jim Keniston
2007-05-09  0:47   ` Ernie Petrides
2007-05-10 23:13     ` Jim Keniston
2007-05-11 22:31       ` Ernie Petrides
2007-05-11 22:31       ` Ernie Petrides [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-04-20 23:08 Jim Keniston

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=200705112217.l4BMHZ0l013676@pasta.boston.redhat.com \
    --to=petrides@redhat.com \
    --cc=fche@redhat.com \
    --cc=jkenisto@us.ibm.com \
    --cc=lwang@redhat.com \
    --cc=systemtap@sources.redhat.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 read-only IMAP folder(s) and NNTP newsgroup(s).