public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Martin Hunt <hunt@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: David Smith <dsmith@redhat.com>, systemtap@sources.redhat.com
Subject: Re: pre-compiled modules
Date: Mon, 19 Jun 2006 17:23:00 -0000	[thread overview]
Message-ID: <1150737777.2534.14.camel@dragon> (raw)
In-Reply-To: <20060619164051.GP30867@redhat.com>

On Mon, 2006-06-19 at 12:40 -0400, Frank Ch. Eigler wrote:
> Hi -
> 
> dsmith wrote:
> 
> > I've been looking at pre-compiled modules, and in general they should
> > work.  I do have a few questions:
> > 
> > 1) One thing I've been worried about is differing options between
> > compile time and run time.  I believe that most of them should be OK,
> > with the exception of the '-b' relayfs option.  If it was specified at
> > compile time and not at run time (or vice versa), I'm not sure what will
> > happen (since that flag appears to change behavior both at compile time
> > and run time).
> > 
> > Got any ideas here on how to prevent this?

I designed stpd from the beginning to get all its parameters from the
module it is loading. Some, like buffer size, can be overridden at the
command line. However you cannot force the transport; it will use
whatever the module uses.

 
> One possibility would be to remove the run-time meaning of -b: don't
> pass it to stpd any more.  

Stpd doesn't get "-b".  It does recognize "-r", which is a hack. Without
it, stpd runs "stp_check" which used to do all kinds of things including
compiling and loading relayfs if necessary. Now it just
mounts /mnt/relay.  

Anyway, "-r" can probably be safely eliminated. I will make a note to
try it ASAP. 


> Perhaps the value could flow by/within the
> module to the runtime to stpd at run time.  

It does.

> Perhaps the
> stp_check/mount check could be deferred until late in the module
> initialization sequence.  

Probably. That's what I plan to try.

Martin


  parent reply	other threads:[~2006-06-19 17:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1150298740.16471.33.camel@dhcp-2.hsv.redhat.com>
2006-06-19 16:40 ` Frank Ch. Eigler
2006-06-19 16:48   ` Hien Nguyen
2006-06-19 17:23   ` Martin Hunt [this message]
2006-06-27 19:47   ` David Smith
2006-06-27 20:01 Stone, Joshua I
2006-06-27 22:08 ` David Smith
2006-06-28  0:49   ` Roland McGrath
2006-06-28  6:00   ` Roland McGrath
2006-06-30 18:05     ` Frank Ch. Eigler
2006-06-30 19:02       ` Roland McGrath
2006-06-27 23:40 Stone, Joshua I
2006-06-30 23:35 ` Frank Ch. Eigler

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=1150737777.2534.14.camel@dragon \
    --to=hunt@redhat.com \
    --cc=dsmith@redhat.com \
    --cc=fche@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).